2013/6/25 Tom Lane <t...@sss.pgh.pa.us>: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> On 24 June 2013 03:50, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
