Andrew Gierth wrote:
Herewith a patch to implement agg(foo ORDER BY bar) with or without
DISTINCT, etc.
What does that mean? Aggregate functions are supposed to be commutative,
right?
No artificial restrictions are imposed on what
syntactical combinations are allowed. However, ORDER BY is
Folks,
Shouldn't this work and produce a true?
SELECT NULL IS NOT DISTINCT FROM ANY(ARRAY['a',NULL]);
ERROR: syntax error at or near ANY
LINE 1: SELECT NULL IS NOT DISTINCT FROM ANY(ARRAY['a',NULL]);
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778
On Fri, Nov 13, 2009 at 2:15 AM, Bruce Momjian br...@momjian.us wrote:
Personally, I would not propose to impose this rule of first-time
contributors, or even second-time contributors. But by about patch #3
I think everyone should be pitching in.
I hate to ask, but how would we enforce
David Fetter wrote:
Folks,
Shouldn't this work and produce a true?
SELECT NULL IS NOT DISTINCT FROM ANY(ARRAY['a',NULL]);
ERROR: syntax error at or near ANY
LINE 1: SELECT NULL IS NOT DISTINCT FROM ANY(ARRAY['a',NULL]);
It should, but probably depends on whether IS NOT DISTINCT should
On Fri, 2009-11-13 at 08:33 +, Dave Page wrote:
On Fri, Nov 13, 2009 at 2:15 AM, Bruce Momjian br...@momjian.us wrote:
Personally, I would not propose to impose this rule of first-time
contributors, or even second-time contributors. But by about patch #3
I think everyone should be
On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Here's the patch to support Python =3.1 with PL/Python. The
compatibility code is mostly in line with the usual 2-3 C porting
practice and is documented inline.
There was considerable debate
On Nov 13, 2009, at 8:06 AM, Michael Meskes wrote:
On Thu, Nov 12, 2009 at 03:07:27PM -0500, Robert Haas wrote:
If you want to submit patches in a series like this one, they need
to be
considered standalone, I think. The Linux kernel devs work
differently
than us here.
Zoltan broke
On Fri, Nov 13, 2009 at 3:17 PM, Greg Smith g...@2ndquadrant.com wrote:
Yeah, that's the other parts of the industry I was referring to. MySQL
uses semi-synchronous to distinguish between its completely asynchronous
default replication mode and one where it provides a somewhat safer
Florian G. Pflug wrote:
While trying to create a domain over an array type to enforce a certain
shape or certain contents of an array (like the array being only
one-dimensional or not containing NULLs), I've stumbled over what I
believe to be a bug in postgresql 8.4
It seems that check
On Fri, Nov 13, 2009 at 7:54 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Andrew Gierth wrote:
Herewith a patch to implement agg(foo ORDER BY bar) with or without
DISTINCT, etc.
What does that mean? Aggregate functions are supposed to be commutative,
right?
We certainly
Unfortunately with all that payload-length discussion, the other part
of my email regarding ACID compliant behavior got completely lost. I
would appreciate some input on that part also...
Thanks,
Joachim
On Thu, Nov 12, 2009 at 12:17 PM, Joachim Wieland j...@mcknight.de wrote:
On Thu, Nov 12,
Joshua Tolley eggyk...@gmail.com writes:
Am I the only one having problems building 8.1 from git? (Am I the only one
building 8.1 from git?) In a clean repository, I've checked out REL8_1_STABLE,
configured with only one argument, to set --prefix, and make gives me this:
Still does not
On Fri, Nov 13, 2009 at 8:50 AM, Simon Riggs si...@2ndquadrant.com wrote:
What about people who contribute hours and hours of their time in
other ways? Are they required to contribute even more of their time to
review as well, just to help their own occasional code contributions
get through
On Fri, Nov 13, 2009 at 1:57 AM, Robert Haas robertmh...@gmail.com wrote:
I agree. We frequently reject features on the basis that someone
might do something stupid with them. It's lame and counterproductive,
and we should stop. The world contains infinite amounts of lameness,
but that's
Hi Andres,
On Thu, Nov 12, 2009 at 11:32 PM, Andres Freund and...@anarazel.de wrote:
I had some free time so I started to take a look at that patch:
+ PostgresPollingStatusType
+ pqAppnamePoll(PGconn *conn)
...
+ case APPNAME_STATE_OPTION_WAIT:
...
+
On tor, 2009-11-12 at 18:42 -0700, James Pye wrote:
For me, plpython has never been what I would call a pleasure to use,
and many of the gripes that I have with it are, IMO, entrenched far
enough into the implementation that any efforts to change it
would(should? =) cause unacceptable breakage
On fre, 2009-11-13 at 03:16 +, Andrew Gierth wrote:
Caveat: as discussed earlier, this patch changes the behaviour of
array_agg(DISTINCT x) when applied to NULL inputs. Formerly, the NULLs
were unconditionally skipped; now, they are treated just like DISTINCT
or GROUP BY normally do.
The
2009/11/13 Hans-Jürgen Schönig h...@cybertec.at:
On Nov 13, 2009, at 8:06 AM, Michael Meskes wrote:
On Thu, Nov 12, 2009 at 03:07:27PM -0500, Robert Haas wrote:
If you want to submit patches in a series like this one, they need to be
considered standalone, I think. The Linux kernel devs
John Naylor escribió:
Hello everyone,
I was quite intrigued by a discussion that happened this past summer
regarding generation of bootstrap files such as postgres.bki, and the
associated pain points of maintaining the DATA() statements in catalog
headers.
It occurred to me that the
On Fri, Nov 13, 2009 at 5:35 AM, Greg Stark gsst...@mit.edu wrote:
On Fri, Nov 13, 2009 at 1:57 AM, Robert Haas robertmh...@gmail.com wrote:
I agree. We frequently reject features on the basis that someone
might do something stupid with them. It's lame and counterproductive,
and we should
On Fri, 2009-11-13 at 10:26 +, Dave Page wrote:
On Fri, Nov 13, 2009 at 8:50 AM, Simon Riggs si...@2ndquadrant.com wrote:
What about people who contribute hours and hours of their time in
other ways? Are they required to contribute even more of their time to
review as well, just to help
Robert Haas wrote:
create table animals (id serial primary key, name varchar not null);
...
with beings as (select * from animals a1, animals a2) select * from
beings where id = 1;
Doctor, it hurts when I do this.
So stop doing that.
Can't you disambiguate it using a column list
Joachim Wieland wrote:
1. Instead of placing the queue into shared memory only I propose to create a
new subdirectory pg_notify/ and make the queue slru-based, such that we do not
risk blocking. Several people here have pointed out that blocking is a true
no-go for a new listen/notify
On Fri, Nov 13, 2009 at 1:31 PM, Simon Riggs si...@2ndquadrant.com wrote:
Requiring people to write docs or any other patch submission rules has
never been counterproductive. People could easily say, English is not
my first language, therefore I skip all comments and docs. But they
don't,
Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
Alvaro Herrera írta:
I have applied this patch after some tinkering. I mainly added support
for fetch_args: FORWARD opt_from_in name and BACKWARD opt_from_in
name in ecpg.addons which apparently you forgot.
Thanks. Your fix
Robert Haas wrote:
I am personally quite tired of
reviewing patches for people who don't in turn review mine (or
someone's). It makes me feel like not working on this project. If we
can solve that problem without implementing a policy of this type,
that is good. I would much prefer to run
spill to disk and need an efficient storage mechanism. The natural
implementation of this in Postgres would be a table, not the slru. If
This is what I think the people's real problem is, the implementation becomes a
more complex when including payloads (larger ones even more so). I think
Simon Riggs wrote:
Requiring people to write docs or any other patch submission rules has
never been counterproductive. People could easily say, English is not
my first language, therefore I skip all comments and docs. But they
don't, because we require that, as a hard rule. Nobody has ever
On Fri, 2009-11-13 at 13:34 +, Dave Page wrote:
On Fri, Nov 13, 2009 at 1:31 PM, Simon Riggs si...@2ndquadrant.com wrote:
Requiring people to write docs or any other patch submission rules has
never been counterproductive. People could easily say, English is not
my first language,
On Fri, Nov 13, 2009 at 1:47 PM, Andrew Chernow a...@esilo.com wrote:
This is what I think the people's real problem is, the implementation
becomes a more complex when including payloads (larger ones even more so).
I think its a side-track to discuss queue vs condition variables. Whether
a
On Fri, 2009-11-13 at 08:46 -0500, Andrew Dunstan wrote:
Organizing contributors on a project like this is like herding cats.
Threats and penalties are unlikely to be effective.
People have spoken against this because of the enforcement issue. If we
talk about this like we were suggesting
Grzegorz Jaśkiewicz wrote:
Dnia czwartek 12 listopad 2009 o 22:14:14 Andrew Dunstan napisał(a):
Grzegorz Jaskiewicz wrote:
consistently fails when compiled on ubuntu 9.10 here (on mini
10v).
+ ERROR: incompatible library
Simon Riggs wrote:
On Fri, 2009-11-13 at 08:47 -0500, Bruce Momjian wrote:
We do ask people to write docs, but I
don't think we will reject patches if people don't supply docs.
Yes, that is a good example. It's a rule, plain and simple. Nobody
gets their spleen removed for breaking it,
On Fri, 2009-11-13 at 09:31 -0500, Bruce Momjian wrote:
Well, right now we ask for docs, but if they are not supplied, I think
we just write them ourselves. Is a different enforcement method being
suggested here?
And we never bump late patches, nor reject them if sent in missing
format etc.
On Fri, Nov 13, 2009 at 8:47 AM, Bruce Momjian br...@momjian.us wrote:
The docs case is a good example. We do ask people to write docs, but I
don't think we will reject patches if people don't supply docs. I am
not against any of the ideas suggested in this thread --- I am just
pointing out
On Fri, 2009-11-13 at 08:47 -0500, Bruce Momjian wrote:
We do ask people to write docs, but I
don't think we will reject patches if people don't supply docs.
Yes, that is a good example. It's a rule, plain and simple. Nobody
gets their spleen removed for breaking it, yet it is still somehow
Dnia czwartek 12 listopad 2009 o 22:14:14 Andrew Dunstan napisał(a):
Grzegorz Jaskiewicz wrote:
consistently fails when compiled on ubuntu 9.10 here (on mini
10v).
+ ERROR: incompatible library
/home/kgrittn/postgresql-8.4.0/src/test/regress/refint.so: version
mismatch
+ DETAIL: Server
Robert Haas wrote:
On Fri, Nov 13, 2009 at 8:47 AM, Bruce Momjian br...@momjian.us wrote:
The docs case is a good example. We do ask people to write docs, but I
don't think we will reject patches if people don't supply docs. I am
not against any of the ideas suggested in this thread ---
Calling this a creeping feature is quite a leap.
It's true that the real creep is having the payload at all rather than
not having it.
Not having the payload at all is like santa showing up without his bag
of toys. Instead, you have to drive/fly to the north pole where he just
came from to
Peter Eisentraut pete...@gmx.net writes:
On fre, 2009-11-13 at 03:16 +, Andrew Gierth wrote:
Caveat: as discussed earlier, this patch changes the behaviour of
array_agg(DISTINCT x) when applied to NULL inputs. Formerly, the NULLs
were unconditionally skipped; now, they are treated just
Joshua Tolley wrote:
Some items of note include that this makes the regression tests add not only
plperl to the test database but also plperlu, which is a new thing. I can't
see why this might cause problems, but thought I'd mention it. The tests
specifically try to verify that plperl doesn't
On Fri, Nov 13, 2009 at 8:46 AM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
I am personally quite tired of
reviewing patches for people who don't in turn review mine (or
someone's). It makes me feel like not working on this project. If we
can solve that problem without
On Fri, Nov 13, 2009 at 10:00 AM, Andrew Chernow a...@esilo.com wrote:
I think the original OP was close. The structure can still be fixed length
but maybe we can bump it to 8k (BLCKSZ)?
The problem with this (which I basically agree with) is that this will
greatly increase the size of the
* Andrew Dunstan and...@dunslane.net [091113 09:52]:
In that case people are working on their own patches. That's quite
different from asking/requiring them to work on somebody else's.
But is it?
Just s/patches/itches/
i.e. The patched code implenting feature $X is their main itch... They
Attached patch fixed following warning:
../../../src/include/nodes/parsenodes.h, line 487: warning: enumerator
value overflows INT_MAX (2147483647)
The reason is clear, enum is int not unsigned.
It is short fix, but I'm thinking about enum conversion to #define. We
use e.g. in the same file.
Greg Stark gsst...@mit.edu writes:
On Fri, Nov 13, 2009 at 7:54 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Andrew Gierth wrote:
Herewith a patch to implement agg(foo ORDER BY bar) with or without
DISTINCT, etc.
What does that mean? Aggregate functions are supposed to
On fre, 2009-11-13 at 10:01 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On fre, 2009-11-13 at 03:16 +, Andrew Gierth wrote:
Caveat: as discussed earlier, this patch changes the behaviour of
array_agg(DISTINCT x) when applied to NULL inputs. Formerly, the NULLs
were
On fre, 2009-11-13 at 10:35 -0500, Tom Lane wrote:
I'm not entirely convinced that adding ORDER BY here is a good idea,
partly because it goes so far beyond the spec
This is exactly the syntax that is in the spec AFAICT.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Heikki Linnakangas wrote:
Agreed, it's a bug. A simpler example is just: [snipped]
Will this fix for this be included in 8.4.2 (or .3), or will it have to
wait for 8.4 because it changes behavior?
There's a special case in transformExpr function to handle the
ARRAY[...]::arraytype construct,
CREATE OR REPLACE FUNCTION incr(stuff int[]) RETURNS int[] AS $$
for x in stuff:
yield x+1
$$
LANGUAGE 'plpythonu';
# select incr(ARRAY[1,2,3]);
ERROR: invalid memory alloc request size 18446744073709551608
CONTEXT: while creating return value
PL/Python function incr
Suppose, it could
On Fri, Nov 13, 2009 at 8:34 AM, Dave Page dp...@pgadmin.org wrote:
On Fri, Nov 13, 2009 at 1:31 PM, Simon Riggs si...@2ndquadrant.com wrote:
Requiring people to write docs or any other patch submission rules has
never been counterproductive. People could easily say, English is not
my first
On Fri, Nov 13, 2009 at 8:32 AM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
create table animals (id serial primary key, name varchar not null);
...
with beings as (select * from animals a1, animals a2) select * from
beings where id = 1;
Doctor, it hurts when I
On Fri, Nov 13, 2009 at 8:16 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I had a look at this some time ago and I must admit that I find it
pretty interesting. The technology choices make it
obviously impossible to merge -- not only the particular Perl modules
used, but the mere fact
Simon Riggs si...@2ndquadrant.com writes:
All the CF manager needs to do is ensure that every patch submitted
chalks up one review. If you think about it, we wouldn't actually need
any rr reviewers at all then, because if we have 20 patches we would
have 20 reviews due. So the whole scheme is
On Fri, Nov 13, 2009 at 3:54 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Nov 13, 2009 at 8:16 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I had a look at this some time ago and I must admit that I find it
pretty interesting. The technology choices make it
obviously
Merlin Moncure mmonc...@gmail.com writes:
The problem with this (which I basically agree with) is that this will
greatly increase the size of the queue for all participants of this
feature if they use the payload or not. I think it boils down to
this: is there a reasonably effective way of
On Fri, Nov 13, 2009 at 10:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
All the CF manager needs to do is ensure that every patch submitted
chalks up one review. If you think about it, we wouldn't actually need
any rr reviewers at all then, because if we
Florian G. Pflug wrote:
Heikki Linnakangas wrote:
Agreed, it's a bug. A simpler example is just: [snipped]
Will this fix for this be included in 8.4.2 (or .3), or will it have to
wait for 8.4 because it changes behavior?
It's a regression; 8.3 and earlier used to check the domain constraint
On Fri, Nov 13, 2009 at 11:00 AM, Dave Page dp...@pgadmin.org wrote:
On Fri, Nov 13, 2009 at 3:54 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Nov 13, 2009 at 8:16 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I had a look at this some time ago and I must admit that I find it
On Fri, Nov 13, 2009 at 10:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark gsst...@mit.edu writes:
On Fri, Nov 13, 2009 at 7:54 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Andrew Gierth wrote:
Herewith a patch to implement agg(foo ORDER BY bar) with or without
On Fri, Nov 13, 2009 at 4:12 PM, Robert Haas robertmh...@gmail.com wrote:
Yep, it's only on UNIX-ish systems where Perl isn't necessarily
required, and realistically I think it is probably present on nearly
all of those, too.
Exactly.
--
Dave Page
EnterpriseDB UK:
Merlin Moncure wrote:
On Fri, Nov 13, 2009 at 10:00 AM, Andrew Chernow a...@esilo.com wrote:
I think the original OP was close. The structure can still be fixed length
but maybe we can bump it to 8k (BLCKSZ)?
The problem with this (which I basically agree with) is that this will
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Florian G. Pflug wrote:
It seems that check constraints on domains are *not* executed for
literals of the domain-over-array-type - in other words, for expressions
like:
array[...]::my-domain-over-array-type.
There's a special
Heikki == Heikki Linnakangas heikki.linnakan...@enterprisedb.com
writes:
Herewith a patch to implement agg(foo ORDER BY bar) with or
without DISTINCT, etc.
Heikki What does that mean? Aggregate functions are supposed to be
Heikki commutative, right?
The SQL spec defines two
Peter == Peter Eisentraut pete...@gmx.net writes:
I'm not entirely convinced that adding ORDER BY here is a good idea,
partly because it goes so far beyond the spec
Peter This is exactly the syntax that is in the spec AFAICT.
Right. The spec defines this syntax for array_agg and xmlagg
Dave Page dp...@pgadmin.org writes:
On Fri, Nov 13, 2009 at 4:12 PM, Robert Haas robertmh...@gmail.com wrote:
Yep, it's only on UNIX-ish systems where Perl isn't necessarily
required, and realistically I think it is probably present on nearly
all of those, too.
Exactly.
Yeah. Although the
Andrew Gierth and...@tao11.riddles.org.uk writes:
Peter == Peter Eisentraut pete...@gmx.net writes:
Peter This is exactly the syntax that is in the spec AFAICT.
Right. The spec defines this syntax for array_agg and xmlagg (only).
Cool, I had forgotten that they added that in the latest
Robert Haas wrote:
On Fri, Nov 13, 2009 at 10:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
All the CF manager needs to do is ensure that every patch submitted
chalks up one review. If you think about it, we wouldn't actually need
any rr reviewers at all
Tom Lane wrote:
Hm. I concur that this special-case code is failing to consider the
possibility that the target type is domain-over-array-type rather than
just array-type. I think though that this patch is a bit of a kluge,
because it delivers a mislabeled expression tree. The result of the
On Friday 13 November 2009 16:35:08 Tom Lane wrote:
Greg Stark gsst...@mit.edu writes:
On Fri, Nov 13, 2009 at 7:54 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Andrew Gierth wrote:
Herewith a patch to implement agg(foo ORDER BY bar) with or without
DISTINCT, etc.
Simon Riggs wrote:
On Fri, 2009-11-13 at 09:31 -0500, Bruce Momjian wrote:
Well, right now we ask for docs, but if they are not supplied, I think
we just write them ourselves. Is a different enforcement method being
suggested here?
And we never bump late patches, nor reject them if
Hi
I'm currently working on a project where we need to build a global cache
table containing all values of certain types found in any of the other
tables. Currently, a seperate insert, update and delete (plpgsql)
trigger function exists for each table in the database which is
auto-generated by a
2009/11/14 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
I think we (the commitfest manager?) should simply send polite message
to any regulars who submits patches but hasn't volunteered for review.
Along the lines of:
I certainly endorse Heikki's suggestion, but I wonder if we can
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
This is BS. The problem is not that someone might do something stupid
with this feature. The problem is that we're making these other use
cases into
Robert Haas wrote:
Please don't sabotage my effort to ensure
an adequate supply of reviewers unless you have a competing proposal.
I don't think you can reasonably demand this. If I don't think your
suggestion is going to improve matters I have a right to say so.
cheers
andrew
--
On Fri, Nov 13, 2009 at 12:18 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I agree with Tom though that we don't really need a huge pool of people
who chip in with one hour per month. We need people who know the
codebase pretty well, and who can spend a fair amount of time
On Fri, Nov 13, 2009 at 12:32 PM, Brendan Jurd dire...@gmail.com wrote:
I'm thinking of something like a Reviewer Hall of Fame, or Honour
Roll. During and after a commitfest, it shows how many reviews have
been completed by each person [1].
This could be included in the Weekly News at the
Florian G. Pflug f...@phlo.org writes:
I'd like to replace this function-generating function by a generic
trigger function that works for all tables. Due to the lack of any way
to inspect the *structure* of a record type, however, I'd have to use a
C language function for that, which induces
Greg Sabino Mullane g...@turnstep.com writes:
Talk of efficiency also seems silly here - using
shared memory is already way more efficient than our current listen/notify
system.
Except that the proposed implementation spills to disk. Particularly if
it has to have support for large payloads,
Simon Riggs wrote:
All the CF manager needs to do is ensure that every patch submitted
chalks up one review. If you think about it, we wouldn't actually need
any rr reviewers at all then, because if we have 20 patches we would
have 20 reviews due. So the whole scheme is self-balancing
In fact,
On fre, 2009-11-13 at 15:05 +0100, Grzegorz Jaśkiewicz wrote:
As per Tom's - yes, this laptop has LANG set to UTF8 Polish. Setting
it back to EN actually makes this error go away.
The Polish locale isn't supported by the regression tests.
--
Sent via pgsql-hackers mailing list
Heikki == Heikki Linnakangas heikki.linnakan...@enterprisedb.com
writes:
No artificial restrictions are imposed on what syntactical
combinations are allowed. However, ORDER BY is not allowed with
aggregates used as window functions (as per the existing
restriction on DISTINCT).
On Fri, Nov 13, 2009 at 12:37 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
Please don't sabotage my effort to ensure
an adequate supply of reviewers unless you have a competing proposal.
I don't think you can reasonably demand this. If I don't think your
suggestion is
Tom Lane wrote:
Greg Sabino Mullane g...@turnstep.com writes:
Talk of efficiency also seems silly here - using
shared memory is already way more efficient than our current listen/notify
system.
Except that the proposed implementation spills to disk. Particularly if
it has to have support for
2009/11/14 Andrew Gierth and...@tao11.riddles.org.uk:
Heikki == Heikki Linnakangas heikki.linnakan...@enterprisedb.com
writes:
No artificial restrictions are imposed on what syntactical
combinations are allowed. However, ORDER BY is not allowed with
aggregates used as window functions
On Nov 13, 2009, at 4:47 AM, Peter Eisentraut wrote:
Has this list of gripes ever been brought up and discussed in this
forum?
Some are TODOs, so in part by other people. Some were briefly touched on in the
recent past discussions(around the time that I announced the WIP). Native
typing vs
On Fri, November 13, 2009 1:04 pm, Robert Haas wrote:
the mere fact that we are even *discussing*
whether it should be mandatory has led to a bumper crop of reviewers,
Non sequitur.
I think it is more likely that the bumper crop of reviewers is due
to the lengthy discussion about the lack of
2009/11/14 Tom Lane t...@sss.pgh.pa.us:
Andrew Gierth and...@tao11.riddles.org.uk writes:
Peter == Peter Eisentraut pete...@gmx.net writes:
Peter This is exactly the syntax that is in the spec AFAICT.
Right. The spec defines this syntax for array_agg and xmlagg (only).
Cool, I had
Tom Lane escribió:
Dave Page dp...@pgadmin.org writes:
On Fri, Nov 13, 2009 at 4:12 PM, Robert Haas robertmh...@gmail.com wrote:
Yep, it's only on UNIX-ish systems where Perl isn't necessarily
required, and realistically I think it is probably present on nearly
all of those, too.
I just noticed that plpgsql's OPEN cursor FOR EXECUTE command lacks
a USING clause, so the only way to put parameters into the string is
textual insertion. Seems like an oversight, since every other variant
of EXECUTE in plpgsql can do USING. Did we omit that intentionally?
On Fri, Nov 13, 2009 at 5:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Quite. This is another instance of the thing I complained of before,
that the SQL committee likes to define the behavior of specific
aggregates instead of inducing a generic aggregate-behavior definition.
I think this makes
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Yeah. Although the project policy is that we don't require Perl to
build on Unix, there was a bug in the makefiles that made it effectively
required, and nobody noticed for several years. I don't think it would
be a hard
On Fri, Nov 13, 2009 at 2:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane escribió:
Yeah. Although the project policy is that we don't require Perl to
build on Unix, there was a bug in the makefiles that made it effectively
required, and
Peter Eisentraut pete...@gmx.net writes:
On fre, 2009-11-13 at 15:05 +0100, Grzegorz JaÅkiewicz wrote:
As per Tom's - yes, this laptop has LANG set to UTF8 Polish. Setting
it back to EN actually makes this error go away.
The Polish locale isn't supported by the regression tests.
With only
Tom Lane wrote:
Florian G. Pflug f...@phlo.org writes:
I'd like to replace this function-generating function by a generic
trigger function that works for all tables. Due to the lack of any
way to inspect the *structure* of a record type, however, I'd have
to use a C language function for that,
Heikki Linnakangas wrote:
Tom Lane wrote:
Hm. I concur that this special-case code is failing to consider the
possibility that the target type is domain-over-array-type rather than
just array-type. I think though that this patch is a bit of a kluge,
because it delivers a mislabeled
In GetSnapshotData(), we set subcount to -1 if the snapshot was overflowed:
subcount = GetKnownAssignedTransactions(snapshot-subxip,
xmin, xmax, overflow);
/*
2009/11/13 Tom Lane t...@sss.pgh.pa.us:
I just noticed that plpgsql's OPEN cursor FOR EXECUTE command lacks
a USING clause, so the only way to put parameters into the string is
textual insertion. Seems like an oversight, since every other variant
of EXECUTE in plpgsql can do USING. Did we
On 13 Nov 2009, at 19:39, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On fre, 2009-11-13 at 15:05 +0100, Grzegorz Jaśkiewicz wrote:
As per Tom's - yes, this laptop has LANG set to UTF8 Polish. Setting
it back to EN actually makes this error go away.
The Polish locale isn't
My original intention was to have the queue as a circular buffer where
the size of the entries was variable, but possibly bounded. Certainly
using fixed length records of large size seems somewhat wasteful.
Maybe we should do away with 'spill to disk' all together and either
hard-code an
1 - 100 of 139 matches
Mail list logo
