Re: [HACKERS] FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
Noah Misch said: I twitched upon reading this, because neither ORDER BY nor FILTER preclude the aggregate being MIN or MAX. Perhaps Andrew can explain why he put aggorder there back in 2009. The bottom line is that I intentionally avoided assuming that an agg with an aggsortop could only be min() or max() and that having an order by clause would always be harmless in such cases. I can't think of an actual use case where it would matter, but I've seen people define some pretty strange aggs recently. So I mildly object to simply throwing away the ORDER BY clause in such cases. -- 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
Re: [HACKERS] FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
On 27 June 2013 15:05, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Gierth and...@tao11.riddles.org.uk writes: Tom Lane said: Agreed, separating out the function-call-with-trailing-declaration syntaxes so they aren't considered in FROM and index_elem seems like the best compromise. If we do that for window function OVER clauses as well, can we make OVER less reserved? Yes. At least, I tried it with both OVER and FILTER unreserved and there were no grammar conflicts (and I didn't have to do anything fancy to avoid them), and it passed regression with the exception of the changed error message for window functions in the from-clause. So is this the final decision on how to proceed? It seems good to me, and I can work with David to get it done. Yeah, please submit a separate patch that just refactors the existing grammar as above; that'll simplify reviewing. In that case, I'll re-review the latest FILTER patch over the weekend on the understanding that the reserved/unreserved keyword issue will be resolved in separate patch. Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
Tom Lane said: Agreed, separating out the function-call-with-trailing-declaration syntaxes so they aren't considered in FROM and index_elem seems like the best compromise. If we do that for window function OVER clauses as well, can we make OVER less reserved? Yes. At least, I tried it with both OVER and FILTER unreserved and there were no grammar conflicts (and I didn't have to do anything fancy to avoid them), and it passed regression with the exception of the changed error message for window functions in the from-clause. So is this the final decision on how to proceed? It seems good to me, and I can work with David to get it done. -- 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
Re: [HACKERS] FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
Hello 2013/6/27 Andrew Gierth and...@tao11.riddles.org.uk: Tom Lane said: Agreed, separating out the function-call-with-trailing-declaration syntaxes so they aren't considered in FROM and index_elem seems like the best compromise. If we do that for window function OVER clauses as well, can we make OVER less reserved? Yes. At least, I tried it with both OVER and FILTER unreserved and there were no grammar conflicts (and I didn't have to do anything fancy to avoid them), and it passed regression with the exception of the changed error message for window functions in the from-clause. So is this the final decision on how to proceed? It seems good to me, and I can work with David to get it done. Isn't dangerous do OVER unreserved keyword?? Regards Pavel -- 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
Andrew Gierth and...@tao11.riddles.org.uk writes: Tom Lane said: Agreed, separating out the function-call-with-trailing-declaration syntaxes so they aren't considered in FROM and index_elem seems like the best compromise. If we do that for window function OVER clauses as well, can we make OVER less reserved? Yes. At least, I tried it with both OVER and FILTER unreserved and there were no grammar conflicts (and I didn't have to do anything fancy to avoid them), and it passed regression with the exception of the changed error message for window functions in the from-clause. So is this the final decision on how to proceed? It seems good to me, and I can work with David to get it done. Yeah, please submit a separate patch that just refactors the existing grammar as above; that'll simplify reviewing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
Pavel Stehule pavel.steh...@gmail.com writes: Tom Lane said: If we do that for window function OVER clauses as well, can we make OVER less reserved? Isn't dangerous do OVER unreserved keyword?? How so? The worst-case scenario is that we find we have to make it more reserved again in some future release, as a consequence of some new randomness from the SQL committee. That will just return us to the status quo, in which anybody who uses OVER as a table/column name has been broken since about 8.4. Since we still hear of people using releases as old as 7.2.x, I'm sure there are a few out there who would still be helped if we could de-reserve OVER again. (Not to mention people migrating from other systems in which it's not a keyword.) In any case, the general project policy has been to never make keywords any more reserved than we absolutely have to. If we didn't care about this, we wouldn't be bothering with four separate categories of keywords. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
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
Re: [HACKERS] FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
Andrew Gierth and...@tao11.riddles.org.uk writes: 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). Agreed, separating out the function-call-with-trailing-declaration syntaxes so they aren't considered in FROM and index_elem seems like the best compromise. If we do that for window function OVER clauses as well, can we make OVER less reserved? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]
Greg Stark st...@mit.edu wrote: On Mon, Jun 24, 2013 at 3:50 AM, Tom Lane t...@sss.pgh.pa.us wrote: Or maybe they really don't give a damn about breaking applications every time they invent a new reserved word? I think this is the obvious conclusion. In the standard the reserved words are pretty explicitly reserved and not legal column names, no? I think their model is that applications work with a certain version of SQL and they're not expected to work with a new version without extensive updating. IMO it is insanity to write an application of any significant complexity without a data abstraction layer sitting on a data access layer, and it is silly to write such layers which are intended to interface to SQL in a portable way without quoting *all* identifiers sent to the server. As a developer, new reserved words never bothered me in the slightest. At Wisconsin Courts the most heavily used table has been called Case since 1989, and the table to hold a row for each paper document printed to pay someone is called Check. No need to change the names just because SQL started using those words for new language features after we had the tables. And there is no reason to assume that any particular word won't become reserved in the future. I think the most likely explanation is not that they don't mind breaking applications, but that they don't understand that there are significant numbers of people who choose to write code in a fashion which leaves them vulnerable to breakage when new reserved words are added. Being closer to the wide variety of users we know that there are many such people out there, and we try to look after them as best we can; which is entirely appropriate. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
