On Sun, Jun 23, 2013 at 07:44:26AM -0700, Kevin Grittner wrote: > Dean Rasheed <dean.a.rash...@gmail.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.
I'm not entirely sure that I agree with this. The SQL standard doesn't go adding keywords willy-nilly, or at least hasn't over a fairly long stretch of time. I can get precise numbers on this if needed. So far, only Tom and Greg have weighed in, Greg's response being here: http://www.postgresql.org/message-id/CAM-w4HOd3N_ozMygs==lm5+hu8yqkkayutgjinp6z2hazdr...@mail.gmail.com > > 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. I think reducing the usefulness of error messages is something we need to think extremely hard about before we do. Is there maybe a way to keep the error messages even if by some magic we manage to unreserve the words? > This also helps keep down the size of the generated parse tables, > doesn't it? Could well. I suspect we may need to rethink the whole way we do grammar at some point, but that's for a later discussion when I (or someone else) has something choate to say about it. Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers