Robert Haas [EMAIL PROTECTED] writes:
It looks to me like section 34.10 of the docs might benefit from some
sort of update in light of this patch, since the builtin array_agg now
does the same thing as the proposed user-defined array_accum, only
better. Presumably we should either pick a
On Thu, Nov 20, 2008 at 4:11 PM, Tom Lane [EMAIL PROTECTED] wrote:
Robert Haas [EMAIL PROTECTED] writes:
It looks to me like section 34.10 of the docs might benefit from some
sort of update in light of this patch, since the builtin array_agg now
does the same thing as the proposed user-defined
Jeff Davis wrote:
Here's an updated patch for just array_accum() with some simple docs.
I have committed a best of Robert Haas and Jeff Davis array_agg()
function with standard SQL semantics. I believe this gives the best
consistency with other aggregate functions for the no-input-rows
Peter Eisentraut [EMAIL PROTECTED] writes:
Jeff Davis wrote:
Here's an updated patch for just array_accum() with some simple docs.
I have committed a best of Robert Haas and Jeff Davis array_agg()
function with standard SQL semantics. I believe this gives the best
consistency with other
Tom Lane wrote:
The original reason for doing this work, I think, was to let us
deprecate contrib/intagg, or at least turn it into a thin wrapper
around core-provided functionality. We now have the means to do that
for int_array_aggregate, but what about int_array_enum?
And what about the
It seems that it would be an easy evening's work to implement unnest(),
at least in the simple form
function unnest(anyarray) returns setof anyelement
without the WITH ORDINALITY syntax proposed by the SQL spec. Then
we could eliminate intagg's C code altogether, and just write it
It looks to me like section 34.10 of the docs might benefit from some
sort of update in light of this patch, since the builtin array_agg now
does the same thing as the proposed user-defined array_accum, only
better. Presumably we should either pick a different example, or add
a note that a
Here's an updated patch for just array_accum() with some simple docs. If
I should document this in more places, let me know.
I decided not to include array_agg() in this patch because it doesn't
support the standard's ORDER BY clause.
My reasoning is that, if someone is using the standard
On Wed, 2008-10-29 at 00:08 -0400, Robert Haas wrote:
It's worth noting that this is the third version of this idea that has
been submitted. Ian Caulfield submitted a patch to add this, and so
did I. Someone should probably look at all three of them and compare.
If we include a function
On Thu, Oct 30, 2008 at 11:19:15PM -0700, Jeff Davis wrote:
If there are potential problems with the standard
(where we don't want to implement a violation), we should just do
array_accum(). If not, we might as well do the standard array_agg(),
perhaps without the ORDER BY clause.
I've wanted
It's worth noting that this is the third version of this idea that has
been submitted. Ian Caulfield submitted a patch to add this, and so
did I. Someone should probably look at all three of them and compare.
...Robert
On Mon, Oct 27, 2008 at 1:41 PM, Jeff Davis [EMAIL PROTECTED] wrote:
On
On Sun, 2008-10-26 at 23:02 -0400, Tom Lane wrote:
Ian Caulfield [EMAIL PROTECTED] writes:
I think array_agg also keeps nulls - although the draft standard I
have seems to contradict itself about this...
The SQL:2008 draft I have says, in 10.9 aggregate function general
rule 8g
I
Tom Lane wrote:
A larger objection to Jeff's draft patch is that it doesn't implement
the sort specification list. I'm entirely happy about not doing that
--- the current SQL committee's willingness to invent random new syntax
and nonorthogonal behavior for every function they can think of will
Peter Eisentraut [EMAIL PROTECTED] writes:
How else will you tell an aggregate function whose result depends on the
input order which order you want?
You feed it from a subquery that has ORDER BY. The only reason the spec
needs this kluge is their insistence that ORDER BY not be used in
On Mon, 2008-10-27 at 18:47 +0200, Peter Eisentraut wrote:
How else will you tell an aggregate function whose result depends on the
input order which order you want? The only aggregates defined in the
standard where this matters are array_agg, array_accum, and xmlagg, but
I don't see
Here is a patch to support two aggregate functions:
1) ARRAY_AGG() -- SQL 2008 standard behavior, returns NULL on no input,
and skips NULL inputs.
2) ARRAY_ACCUM() -- Returns empty array on no input, and includes NULL
inputs.
These accumulate the result in a memory context that lives across
I think array_agg also keeps nulls - although the draft standard I
have seems to contradict itself about this...
Ian
2008/10/26 Jeff Davis [EMAIL PROTECTED]:
Here is a patch to support two aggregate functions:
1) ARRAY_AGG() -- SQL 2008 standard behavior, returns NULL on no input,
and skips
Jeff,
* Jeff Davis ([EMAIL PROTECTED]) wrote:
2) ARRAY_ACCUM() -- Returns empty array on no input, and includes NULL
inputs.
Excellent.. I added it the easy way (from the online docs), but that's
clearly not at all efficient and was going to try and fix it, for psql
to use with the
Ian Caulfield [EMAIL PROTECTED] writes:
I think array_agg also keeps nulls - although the draft standard I
have seems to contradict itself about this...
The SQL:2008 draft I have says, in 10.9 aggregate function general
rule 8g
NOTE 267 - Null values are not eliminated when computing
19 matches
Mail list logo
