On Sun, Nov 8, 2009 at 4:41 PM, Jeff Davis wrote:
> On Sat, 2009-11-07 at 10:56 -0800, Jeff Davis wrote:
>> EXCLUDE probably flows most nicely with the optional USING clause or
>> without. My only complaint was that it's a transitive verb, so it seems
>> to impart more meaning than it actually can
On Fri, Nov 13, 2009 at 11:06 PM, Bruce Momjian wrote:
> Having read the discussion and heard people's opinions, I am now
> thinking that I need to get more involved in committing patches.
Woot.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Robert Haas wrote:
> Anyhow, as Bruce pointed out on another message, in some sense we are
> getting sidetracked. Good reviewers opting out of the system *is* a
> problem, but lack of a sufficient number of sufficiently involved
> committers is a bigger one.
I want to thank everyone for the fine
(I'm not sure I should piping up here, so feel free to ignore, but
perhaps I have something small to offer. I've been following the list
for a while, but try to keep my mouth shut.)
On 13/11/2009 3:07 AM, Selena Deckelmann wrote:
> * Distributed revision control as standard for the project
This
Scott Bailey wrote:
Chris Graner wrote:
Hello,
I've been reading over the documentation to find an alternative to
the deprecated xpath_table functionality. I think it may be a
possibility but I'm not seeing a clear alternative.
Thanks,
Chris Graner
The standard is XMLTABLE and is imple
--On 13. November 2009 19:08:22 -0500 Tom Lane wrote:
It looks to me like the code in AlterSetting() will allow an ordinary
user to blow away all settings for himself. Even those that are for
SUSET variables and were presumably set for him by a superuser. Isn't
this a security hole? I woul
On Saturday 14 November 2009 01:03:33 Kevin Grittner wrote:
> It is in context format, applies cleanly, and passes "make check".
Unfortunately the latter is not saying much - I had a bug there and it was not
found by the regression tests. Perhaps I should take a stab and add at least
some more...
Josh Berkus wrote:
Payloads are also quite useful even in a lossy environment, where you
understand that LISTEN is not a queue. For example, I'd like to be
using LISTEN/NOTIFY for cache invalidation for some applications; if it
misses a few, or double-counts them, it's not an issue. However, I'
It looks to me like the code in AlterSetting() will allow an ordinary
user to blow away all settings for himself. Even those that are for
SUSET variables and were presumably set for him by a superuser. Isn't
this a security hole? I would expect that an unprivileged user should
not be able to cha
Kevin Grittner wrote:
> (Note: I personally would much rather see the performance
> penalty addressed this way, and a TODO added for the more invasive
> work, than to leave this alone for the next release if there's nobody
> willing to tackle the problem at a more fundamental level.)
+1
--
Alva
Andres Freund wrote:
> On Sunday 01 November 2009 16:19:43 Andres Freund wrote:
>> While playing around/evaluating tsearch I notices that to_tsvector
>> is obscenely slow for some files. After some profiling I found that
>> this is due using a seperate TSParser in p_ishost/p_isURLPath in
>> wparse
On Fri, 2009-11-13 at 23:10 +0100, Andres Freund wrote:
> I have to admit that at least for me personally its way much easer to get
> started on a patch one finds interesting than when not
I find it much easier to get interested in a patch after I get started
reviewing it ;)
Seriously, that's ha
First attempt at a docs patch for aggregate order by.
--
Andrew.
Index: doc/src/sgml/func.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/func.sgml,v
retrieving revision 1.491
diff -c -r1.491 func.sgml
*** doc/src/sgml/func.
Zdenek Kotala writes:
> 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.
I think the compiler is entitled to assume either, actually.
But your
1Emilio Platzer writes:
> I need to a "double precision" with magniude (ie meters, kilo, dolar,
> etc). And can operate with them (ie dolar+dolar=dolar or
> dolar/dolar=double precision).
> Do you know some pluggin or module to do this?
Yeah, there's a "tagged types" module on pgfoundry or som
I attached patch which was already sent on february/april, but it was
lost in time. It is originally from Robert Lor and Theo Schlossnagle.
It contains two DTrace probe groups. One is related to monitoring SLRU
and second is about executor nodes.
I merged it with the head.
Original end of mail t
On Fri, Nov 13, 2009 at 5:20 PM, Zdenek Kotala wrote:
> Alvaro Herrera píše v pá 13. 11. 2009 v 18:34 -0300:
>> Zdenek Kotala wrote:
>> > Attached patch contains new dtrace probes for memory management. Main
>> > purpose is to analyze memory footprint - for example how many memory
>> > needs trans
Alvaro Herrera píše v pá 13. 11. 2009 v 18:34 -0300:
> Zdenek Kotala wrote:
> > Attached patch contains new dtrace probes for memory management. Main
> > purpose is to analyze memory footprint - for example how many memory
> > needs transaction, peak memory per context, when memory block is reused
On Fri, Nov 13, 2009 at 4:41 PM, Zdenek Kotala wrote:
> Alvaro Herrera píše v pá 13. 11. 2009 v 18:34 -0300:
>> Zdenek Kotala wrote:
>> > Attached patch contains new dtrace probes for memory management. Main
>> > purpose is to analyze memory footprint - for example how many memory
>> > needs trans
On Friday 13 November 2009 18:56:01 Greg Smith wrote:
> Take a look at
> https://commitfest.postgresql.org/action/commitfest_view?id=4 right
> now. I've been suggesting to people that they assign themselves to the
> patches they like, and it's nearing completely populated two days before
> the
On Fri, 2009-11-13 at 12:56 -0500, Greg Smith wrote:
> For now, simply telling submitters that the
> review of their own patches might be influenced by whether they do a
> good job reviewing someone else's has improved things considerably
> over past CommitFests, and it's hard to imagine how som
On Fri, 2009-11-13 at 22:19 +0200, Heikki Linnakangas wrote:
> I got the impression earlier that you had some test environment set up
> to test hot standby. Can you share any details of what test cases
> you've run?
Fair question. The Sep 15 submission happened too quickly for us to
mobilise test
I'm apologize about my poor english
I need to a "double precision" with magniude (ie meters, kilo, dolar,
etc). And can operate with them (ie dolar+dolar=dolar or
dolar/dolar=double precision).
Do you know some pluggin or module to do this?
I can implement it but I need some examples. I try
Alvaro Herrera píše v pá 13. 11. 2009 v 18:34 -0300:
> Zdenek Kotala wrote:
> > Attached patch contains new dtrace probes for memory management. Main
> > purpose is to analyze memory footprint - for example how many memory
> > needs transaction, peak memory per context, when memory block is reused
>
> > Can't you disambiguate it using a column list on beings?
>
> Sure, after I figured out what the real problem was. Maybe I'm a
> dope, but when I get an error cursor pointed at an ambiguous column
> reference, my thought is "oh, I need to qualify that reference" - not
> "oh, some completely u
"Florian G. Pflug" writes:
> Tom Lane wrote:
>> Trying to do this in plpgsql is doomed to failure and heartache,
> Well, the proposed functions at least allow for some more flexibility in
> working with row types, given that you know in advance which types you
> will be dealing with (but not nece
Tom Lane píše v pá 13. 11. 2009 v 16:06 -0500:
> Zdenek Kotala writes:
> > Attached patch contains new dtrace probes for memory management.
>
> This is a bad idea and I want to reject it outright. No ordinary user
> is really going to care about those details, and palloc is a
> sufficiently hot
Zdenek Kotala wrote:
> Attached patch contains new dtrace probes for memory management. Main
> purpose is to analyze memory footprint - for example how many memory
> needs transaction, peak memory per context, when memory block is reused
> or when it is allocate by malloc and so on.
Having had to
On Fri, Nov 13, 2009 at 5:16 AM, Alvaro Herrera
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 that Perl is used (and
On Fri, 2009-11-13 at 15:22 -0600, Kevin Grittner wrote:
> "Joshua D. Drake" wrote:
>
> > Is it possible to have a set of probes that would only be enabled
> > with say, --enable-debug compile time option?
>
> But we routinely build with that for normal production use so that if
> we get a cor
"Joshua D. Drake" wrote:
> Is it possible to have a set of probes that would only be enabled
> with say, --enable-debug compile time option?
But we routinely build with that for normal production use so that if
we get a core dump or need to backtrace a problem process, we will get
meaningful r
"Joshua D. Drake" writes:
> On Fri, 2009-11-13 at 16:06 -0500, Tom Lane wrote:
>> This is a bad idea and I want to reject it outright. No ordinary user
>> is really going to care about those details, and palloc is a
>> sufficiently hot hot-spot that even the allegedly negligible overhead
>> of an
On Fri, 2009-11-13 at 10:46 -0500, Robert Haas wrote:
> To put this another way, if everyone who submitted a patch reviewed a
> patch, we could finish up each CommitFest in 2-3 weeks instead of a
> whole month
Agreed. That's the idea, lets go with it to see if it works.
--
Simon Riggs
On Fri, 2009-11-13 at 10:55 -0500, Tom Lane wrote:
> Simon Riggs 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
> > h
Tom Lane wrote:
Alvaro Herrera 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 sel
On Fri, 2009-11-13 at 16:06 -0500, Tom Lane wrote:
> Zdenek Kotala writes:
> > Attached patch contains new dtrace probes for memory management.
>
> This is a bad idea and I want to reject it outright. No ordinary user
> is really going to care about those details, and palloc is a
> sufficiently
On Fri, 2009-11-13 at 10:12 -0500, Robert Haas wrote:
> Keep in mind that
> this is a problem that *does not apply to you*. You are a committer.
> If no one reviews your patch, you will eventually go ahead and commit
> it anyway. If no one reviews my patch, it doesn't go in.
That is the problem.
Zdenek Kotala writes:
> Attached patch contains new dtrace probes for memory management.
This is a bad idea and I want to reject it outright. No ordinary user
is really going to care about those details, and palloc is a
sufficiently hot hot-spot that even the allegedly negligible overhead
of an
Attached patch contains new dtrace probes for memory management. Main
purpose is to analyze memory footprint - for example how many memory
needs transaction, peak memory per context, when memory block is reused
or when it is allocate by malloc and so on.
There are three groups of probes:
1) gener
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 o
On 13 Nov 2009, at 19:39, Tom Lane wrote:
> Peter Eisentraut 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 suppo
2009/11/13 Tom Lane :
> 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 intenti
In GetSnapshotData(), we set subcount to -1 if the snapshot was overflowed:
> subcount = GetKnownAssignedTransactions(snapshot->subxip,
>
> &xmin, xmax, &overflow);
>
> /*
>
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
Tom Lane wrote:
"Florian G. Pflug" 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 induc
Peter Eisentraut 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 one result
On Fri, Nov 13, 2009 at 2:27 PM, Tom Lane wrote:
> Alvaro Herrera 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.
Alvaro Herrera 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 sell to change that
On Fri, Nov 13, 2009 at 5:09 PM, Tom Lane 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 sense from the po
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?
Tom Lane escribió:
> Dave Page writes:
> > On Fri, Nov 13, 2009 at 4:12 PM, Robert Haas 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. Althoug
2009/11/14 Tom Lane :
> Andrew Gierth writes:
>> "Peter" == Peter Eisentraut 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 revisions.
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 o
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
2009/11/14 Andrew Gierth :
>> "Heikki" == Heikki Linnakangas
>> 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
Tom Lane wrote:
"Greg Sabino Mullane" 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,
On Fri, Nov 13, 2009 at 12:37 PM, Andrew Dunstan 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 going to improv
> "Heikki" == Heikki Linnakangas
> 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).
Heikki> How is this d
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 (pgsql-hacke
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, ju
"Greg Sabino Mullane" 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, it could very
"Florian G. Pflug" 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 quite som
On Fri, Nov 13, 2009 at 12:32 PM, Brendan Jurd 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 CF's conclusion
On Fri, Nov 13, 2009 at 12:18 PM, Heikki Linnakangas
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 to do
> thorough review of comple
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
--
S
-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 r
2009/11/14 Heikki Linnakangas :
> 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 do
more to make reviewing patche
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
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 t
On Friday 13 November 2009 16:35:08 Tom Lane wrote:
> Greg Stark writes:
> > On Fri, Nov 13, 2009 at 7:54 AM, Heikki Linnakangas
> >
> > wrote:
> >> Andrew Gierth wrote:
> >>> Herewith a patch to implement agg(foo ORDER BY bar) with or without
> >>> DISTINCT, etc.
> >>
> >> What does that mean? A
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
Robert Haas wrote:
> On Fri, Nov 13, 2009 at 10:55 AM, Tom Lane wrote:
>> Simon Riggs 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
Andrew Gierth writes:
> "Peter" == Peter Eisentraut 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 revisions.
I withdraw the complaint that t
Dave Page writes:
> On Fri, Nov 13, 2009 at 4:12 PM, Robert Haas 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 project policy is that we don't
> "Peter" == Peter Eisentraut 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 (only)
> "Heikki" == Heikki Linnakangas
> 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 non-commutative aggregates th
Heikki Linnakangas 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[...]::.
> There's a special case in transformExpr function to handle the
> "ARRAY
Merlin Moncure wrote:
On Fri, Nov 13, 2009 at 10:00 AM, Andrew Chernow 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
On Fri, Nov 13, 2009 at 4:12 PM, Robert Haas 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: http://www.enterprisedb.com
--
Sent via pgs
On Fri, Nov 13, 2009 at 10:35 AM, Tom Lane wrote:
> Greg Stark writes:
>> On Fri, Nov 13, 2009 at 7:54 AM, Heikki Linnakangas
>> wrote:
>>> Andrew Gierth wrote:
Herewith a patch to implement agg(foo ORDER BY bar) with or without
DISTINCT, etc.
>>>
>>> What does that mean? Aggregate fun
On Fri, Nov 13, 2009 at 11:00 AM, Dave Page wrote:
> On Fri, Nov 13, 2009 at 3:54 PM, Robert Haas wrote:
>> On Fri, Nov 13, 2009 at 8:16 AM, Alvaro Herrera
>> 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
>>>
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 const
On Fri, Nov 13, 2009 at 10:55 AM, Tom Lane wrote:
> Simon Riggs 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
Merlin Moncure 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 making the payloa
On Fri, Nov 13, 2009 at 3:54 PM, Robert Haas wrote:
> On Fri, Nov 13, 2009 at 8:16 AM, Alvaro Herrera
> 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 P
Simon Riggs 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 self-balancing.
W
On Fri, Nov 13, 2009 at 8:16 AM, Alvaro Herrera
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 that Perl is used (and
On Fri, Nov 13, 2009 at 8:32 AM, Andrew Dunstan 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 hur
On Fri, Nov 13, 2009 at 8:34 AM, Dave Page wrote:
> On Fri, Nov 13, 2009 at 1:31 PM, 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
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
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
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)
On fre, 2009-11-13 at 10:01 -0500, Tom Lane wrote:
> Peter Eisentraut 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 unc
Greg Stark writes:
> On Fri, Nov 13, 2009 at 7:54 AM, Heikki Linnakangas
> 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 cert
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.
* Andrew Dunstan [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
scratch that, an
On Fri, Nov 13, 2009 at 10:00 AM, Andrew Chernow 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 queue for all pa
On Fri, Nov 13, 2009 at 8:46 AM, Andrew Dunstan 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 implementin
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 a
Peter Eisentraut 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 like DISTINC
1 - 100 of 139 matches
Mail list logo
