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

2013-07-15 Thread Andrew Gierth
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

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

2013-06-28 Thread Dean Rasheed
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

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

2013-06-27 Thread Andrew Gierth
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

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

2013-06-27 Thread Pavel Stehule
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

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

2013-06-27 Thread Tom Lane
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

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

2013-06-27 Thread Tom Lane
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

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

2013-06-26 Thread Andrew Gierth
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

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

2013-06-26 Thread Tom Lane
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,

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

2013-06-24 Thread Kevin Grittner
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