Dean Rasheed said: > 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.
Possibly significant in this context is that there is a proof-of-concept patch in development for another part of T612, namely inverse distribution functions (e.g. percentile_disc and percentile_cont) which should be available by the next CF, and which will require a similar decision with respect to the keyword WITHIN (to support doing: select percentile_cont(0.5) within group (order by x) from ...; which returns the median value of x). This syntax is much more widely supported than FILTER, including by both Oracle and MSSQL, so a non-standard alternative is much less attractive. A solution which suits both (i.e. either option 1 or option 2) would make a whole lot more sense than trying to handle them differently. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
