On Sun, Dec 16, 2012 at 3:18 AM, Tom Lane wrote:
> Simon Riggs writes:
>> Doing that only makes sense when we're running a SELECT. Setting the
>> all visible bit immediately prior to an UPDATE that clears it again is
>> pointless effort, generating extra work for no reason.
>
> On the other hand,
On Mon, 2012-12-10 at 20:48 -0600, Karl O. Pinc wrote:
> On 11/14/2012 02:35:54 PM, Karl O. Pinc wrote:
> > On 11/13/2012 08:50:55 PM, Peter Eisentraut wrote:
> > > On Sat, 2012-09-29 at 01:16 -0500, Karl O. Pinc wrote:
> > > > This patch makes some sweeping statements.
> > >
> > > Unfortunately,
On Sat, 2012-11-17 at 12:02 -0600, Karl O. Pinc wrote:
> Feel free to reject. I sent in the patch to
> try out the idea. It's a bit crazy, but I didn't
> think too crazy to share with the list.
I'm going to set this patch as returned with feedback for now. I'm all
for adding more help to the d
I'm going to use PL/Python as an example, but I would also like to know
if this could be applicable to other languages.
When you do
CREATE FUNCTION foo(...) ... LANGUAGE plpythonu
AS $$
source code here
$$;
it internally creates a "source file" that contains
---
def __plpython_procedure_foo_123
On Fri, 2012-12-14 at 15:32 -0500, Andrew Dunstan wrote:
> Here's a patch for that.
It appears that your change has caused new compiler warnings:
encnames.c:9:1: warning: "Assert" redefined
In file included from encnames.c:8:
../../../src/include/postgres_fe.h:36:1: warning: this is the location
On Fri, 2012-12-14 at 17:03 -0500, Tom Lane wrote:
> Having the layer is a good thing, eg so that USE_ASSERT_CHECKING
> can control it, or so that somebody can inject a different behavior
> if they want.
You could also (or at least additionally) map !USE_ASSERT_CHECKING to
NDEBUG. This would als
2012/12/15 Tom Lane :
> Pavel Stehule writes:
>> Is this behave expected?
>
>> -- unexpected
>> postgres=# select * from generate_series(1,3) g(v), LATERAL (SELECT
>> random()) x;
>> ;
>> vrandom
>> ---+--
>> 1 0.63025646051392
>> 2 0.63025646051392
>> 3 0.630256
Pavel Stehule writes:
> Is this behave expected?
> -- unexpected
> postgres=# select * from generate_series(1,3) g(v), LATERAL (SELECT random())
> x;
> ;
> vrandom
> ---+--
> 1 0.63025646051392
> 2 0.63025646051392
> 3 0.63025646051392
> (3 rows)
The LATERAL ke
Hello
I tested some usage of LATERAL clause, and I found so LATERAL doesn't
respects difference between VOLATILE and IMMUTABLE functions.
Is this behave expected?
-- unexpected
postgres=# select * from generate_series(1,3) g(v), LATERAL (SELECT random()) x;
;
v │ random
───┼───
Simon Riggs writes:
> Doing that only makes sense when we're running a SELECT. Setting the
> all visible bit immediately prior to an UPDATE that clears it again is
> pointless effort, generating extra work for no reason.
On the other hand, the HOT prune operation itself is worthless when
we're ru
On Sat, Dec 15, 2012 at 9:53 PM, Tom Lane wrote:
> =?iso-8859-15?q?C=E9dric_Villemain?= writes:
>> Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit :
>>> $ rm gram.o
>>> rm: remove regular file `gram.o'? y
>>> $ make
>>> make: Nothing to be done for `all'.
>>>
>>> WTF?
>
>> A previous patc
Peter Eisentraut writes:
> In the plperl and plpython makefiles we look for a shared library of
> libperl or libpython, and if it's not found, we check for
> allow_nonpic_in_shlib, and if that's yes, then we proceed anyway.
> Apparently, and IIRC, this was set up in a time when those shared
> libr
"Kevin Grittner" writes:
> Tom Lane wrote:
>> the parser tables are basically number-of-tokens wide by
>> number-of-states high. (In HEAD there are 433 tokens known to the
>> grammar, all but 30 of which are keywords, and 4367 states.)
>>
>> Splitting the grammar into multiple grammars is unlikel
On 15 December 2012 12:42, Pavan Deolasee wrote:
> We discussed this idea in the past [1] and Robert recently again
> mentioned this in another thread [2]. Please see a rebased/revised
> patch attached with the mail. This is mostly similar to what I's
> submitted in [1] except some additions to al
=?iso-8859-15?q?C=E9dric_Villemain?= writes:
> Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit :
>> $ rm gram.o
>> rm: remove regular file `gram.o'? y
>> $ make
>> make: Nothing to be done for `all'.
>>
>> WTF?
> A previous patch changed the ".SECONDARY" from an if() section to the main
On Sat, December 15, 2012 14:10, Magnus Hagander wrote:
> On Sat, Dec 15, 2012 at 11:39 AM, Erik Rijkers wrote:
>> from 9.3devel (this morning):
>
>
>> The truncated name in parentheses only shows up during the filling of the
>> new PGDATA; when 100%
>> is
>> reached that part of the displayed na
On Sat, Dec 15, 2012 at 01:23:38AM -0500, Peter Eisentraut wrote:
> In the plperl and plpython makefiles we look for a shared library of
> libperl or libpython, and if it's not found, we check for
> allow_nonpic_in_shlib, and if that's yes, then we proceed anyway.
> Apparently, and IIRC, this was s
On Sat, Dec 15, 2012 at 11:39 AM, Erik Rijkers wrote:
> from 9.3devel (this morning):
Is this different from 9.2 and earlier?
> There is a small bug in pg_basebackup: it displays a truncated part of what
> seems to be the new
> $PGDATA (the source code has 'filename' there, but I don't see wha
We discussed this idea in the past [1] and Robert recently again
mentioned this in another thread [2]. Please see a rebased/revised
patch attached with the mail. This is mostly similar to what I's
submitted in [1] except some additions to also compute visibility
cut-off XID. I also removed a warnin
Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit :
> In a fully-built source tree:
>
> $ cd pgsql/src/backend/parser
> $ make
> make: Nothing to be done for `all'.
> ... okay so far ...
> $ rm gram.o
> rm: remove regular file `gram.o'? y
> $ make
> make: Nothing to be done for `all'.
>
> W
from 9.3devel (this morning):
There is a small bug in pg_basebackup: it displays a truncated part of what
seems to be the new
$PGDATA (the source code has 'filename' there, but I don't see what's supposed
to be in there).
The truncated name in parentheses only shows up during the filling of the
21 matches
Mail list logo
