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

2013/6/26 Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>:
> On 26 June 2013 01:01, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>
>>> 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.
>>
>> Well, what other DBMSes support this feature? Will being non-spec
>> introduce migration pain?
>>
>
> I can't find any, but that doesn't mean they don't exist, or aren't
> being worked on.
>
> To recap, the options currently on offer are:
>
> 1). Make FILTER a new partially reserved keyword, accepting that that
> might break some users' application code.
>
> 2). Make FILTER unreserved, accepting that that will lead to syntax
> errors rather than more specific error messages if the user tries to
> use an aggregate/window function with FILTER or OVER in the FROM
> clause of a query, or as an index expression.
>
> 3). Adopt a non-standard syntax for this feature, accepting that that
> might conflict with other databases, and that we can never then claim
> to have implemented T612, "Advanced OLAP operations".
>
> 4). Some other parser hack that will offer a better compromise?
>
>
> My preference is for (2) as the lesser of several evils --- it's a
> fairly narrow case where the quality of the error message is reduced.
>

@2 looks well

Pavel

> Regards,
> Dean
>
>
> --
> 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