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)
Re: Proposal/design feedback needed: WITHIN GROUP (sql standard ordered set aggregate functions) |
Список | 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 по дате отправления: