Re: array_agg and array_accum (patch)

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ian Caulfield <ian(dot)caulfield(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Jeff Davis <pgsql(at)j-davis(dot)com>
Subject: Re: array_agg and array_accum (patch)
Date: 2008-10-27 16:47:50
Message-ID: 4905F0B6.4070505@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 be
> the death of SQL yet --- but it's something that we at least need to
> document the workaround for.

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
it would also be useful in other cases such as a text concatenation
aggregate function or an aggregate function to calculate the correlation
(or whatever alternative metric we come up with). Given that the
standard does not provide for user-defined aggregates, I think the way
it's specified is perfectly OK.

Without a way to control the order, how useful are these array
aggregates really?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2008-10-27 16:48:11 Re: WIP: default values for function parameters
Previous Message Tom Lane 2008-10-27 16:46:53 Re: ERRORDATA_STACK_SIZE exceeded (server crash)