From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division] |
Date: | 2013-06-26 08:21:33 |
Message-ID: | CAEZATCXJrMpD1+DOusVNG0fTBFjf+J8kpv9i7=5+p1a0ihXjUQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Szymon Guz | 2013-06-26 08:28:08 | Re: [PATCH] Fix conversion for Decimal arguments in plpython functions |
Previous Message | Simon Riggs | 2013-06-26 08:20:48 | Re: Add visibility map information to pg_freespace. |