Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]

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