Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division] - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
Date
Msg-id CAEZATCXJrMpD1+DOusVNG0fTBFjf+J8kpv9i7=5+p1a0ihXjUQ@mail.gmail.com
Whole thread Raw
In response to Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]  (Josh Berkus <josh@agliodbs.com>)
Responses Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
List pgsql-hackers
On 26 June 2013 01:01, Josh Berkus <josh@agliodbs.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.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Add visibility map information to pg_freespace.
Next
From: Szymon Guz
Date:
Subject: Re: [PATCH] Fix conversion for Decimal arguments in plpython functions