2013/6/25 Tom Lane <[email protected]>: > Dean Rasheed <[email protected]> writes: >> On 24 June 2013 03:50, Tom Lane <[email protected]> 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 ([email protected]) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
