Re: Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)
Дата
Msg-id 2184.1374199788@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)  (Noah Misch <noah@leadboat.com>)
Ответы Re: Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)  (Atri Sharma <atri.jiit@gmail.com>)
Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions)  (John Galloway <jgalloway@salesforce.com>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Performance Improvement by reducing WAL for Update Operation
Следующее
От: "Prabakaran, Vaishnavi"
Дата:
Сообщение: Re: Differences in WHERE clause of SELECT