Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
От | Tom Lane |
---|---|
Тема | Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division] |
Дата | |
Msg-id | 8783.1372167730@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division] (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: FILTER for aggregates [was Re: Department of Redundancy
Department: makeNode(FuncCall) division]
|
Список | pgsql-hackers |
Dean Rasheed <dean.a.rasheed@gmail.com> writes: > On 24 June 2013 03:50, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Going on the same principle, we could probably let FILTER be an >> unreserved keyword while FILTER_FOLLOWED_BY_PAREN could be a >> type_func_name_keyword. (I've not tried this though.) > I've not tried either, but wouldn't that mean that "SELECT * FROM > list_filters() filter" would be legal, whereas "SELECT * FROM > list_filters() filter(id, val)" would be a syntax error? If so, I > don't think that would be an improvement. Hm, good point. The SQL committee really managed to choose some unfortunate syntax here, didn't they. I know it's heresy in these parts, but maybe we should consider adopting a non-spec syntax for this feature? In particular, it's really un-obvious why the FILTER clause shouldn't be inside rather than outside the aggregate's parens, like ORDER BY. regards, tom lane
В списке pgsql-hackers по дате отправления: