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
"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
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 builtin
> 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
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 th
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 wit
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 cas
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 array_a
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 wan
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
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 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 arr
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
su
Tom Lane wrote:
A larger objection to Jeff's draft patch is that it doesn't implement
the . 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 be
the death of SQL yet
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 general
> rule 8g
>
I apologize,
"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 general
rule 8g
NOTE 267 - Null values are not eliminated when computing . This, plus t
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 column-
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 s
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
19 matches
Mail list logo
