From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com> |
Subject: | Re: Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions) |
Date: | 2013-07-19 02:09:48 |
Message-ID: | 2184.1374199788@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Prabakaran, Vaishnavi | 2013-07-19 02:21:40 | Re: Differences in WHERE clause of SELECT |
Previous Message | Stephen Frost | 2013-07-19 01:45:56 | Re: Performance Improvement by reducing WAL for Update Operation |