From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division] |
Date: | 2013-06-23 14:44:26 |
Message-ID: | 1371998666.72405.YahooMailNeo@web162903.mail.bf1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> I'm still not happy that this patch is making FILTER a new reserved
> keyword, because I think it is a common enough English word (and an
> obscure enough SQL keyword) that people may well have used it for
> table names or aliases, and so their code will break.
Well, if it is a useful capability with a standard syntax, I think
we should go with the standard syntax even if it might break
application code that uses, as unquoted identifiers, words reserved
by the SQL standard. Of course, non-reserved is better than
reserved if we can manage it.
> Playing around with the idea proposed there, it seems that it is
> possible to make FILTER (and also OVER) unreserved keywords, by
> splitting out the production of aggregate/window functions from normal
> functions in gram.y. Aggregate/window functions are not allowed in
> index_elem or func_table constructs, but they may appear in c_expr's.
> That resolves the shift/reduce conflicts that would otherwise occur
> from subsequent alias clauses, allowing FILTER and OVER to be
> unreserved.
>
> There is a drawback --- certain error messages become less specific,
> for example: "SELECT * FROM rank() OVER(ORDER BY random());" is now a
> syntax error, rather than the more useful error saying that window
> functions aren't allowed in the FROM clause. That doesn't seem like
> such a common case though.
>
> What do you think?
I think it is OK if that gets a syntax error. If that's the "worst
case" I like this approach.
This also helps keep down the size of the generated parse tables,
doesn't it?
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2013-06-23 15:11:15 | Re: A better way than tweaking NTUP_PER_BUCKET |
Previous Message | Kevin Grittner | 2013-06-23 14:25:28 | Re: changeset generation v5-01 - Patches & git tree |