Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
От | Pavel Stehule |
---|---|
Тема | Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division] |
Дата | |
Msg-id | CAFj8pRAYkCe_-0+95zXKByrs1VjPbhvBj5tznBfC7wVg0D+hZg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division] (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2013/6/25 Tom Lane <tgl@sss.pgh.pa.us>: > 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. the gram can be more free and final decision should be done in later stages ??? This technique was enough when I wrote prototype for CUBE ROLLUP without CUBE ROLLUP reserwed keywords. Regards Pavel > > regards, tom lane > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: