Re: Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)
Date
Msg-id 2184.1374199788@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)  (Noah Misch <noah@leadboat.com>)
Responses Re: Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)
Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> (I don't know whether VARIADIC transition functions work today, but that would
> become an orthogonal project.)

Coincidentally enough, some Salesforce folk were asking me about allowing
VARIADIC aggregates just a few days ago.  I experimented enough to find
out that if you make an array-accepting transition function, and then
force the aggregate's pg_proc entry to look like it's variadic (by
manually setting provariadic and some other fields), then everything
seems to Just Work: the parser and executor are both fine with it.
So I think all that's needed here is to add some syntax support to
CREATE AGGREGATE, and probably make some tweaks in pg_dump.  I was
planning to go work on that sometime soon.

Having said that, though, what Andrew seemed to want was VARIADIC ANY,
which is a *completely* different kettle of fish, since the actual
parameters can't be converted to an array.  I'm not sure if that's
as easy to support.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Performance Improvement by reducing WAL for Update Operation
Next
From: "Prabakaran, Vaishnavi"
Date:
Subject: Re: Differences in WHERE clause of SELECT