On Sun, Jun 23, 2013 at 07:44:26AM -0700, Kevin Grittner wrote:
> Dean Rasheed <dean.a.rasheed@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+hU8yQKKaYutGjiNp6z2hAzDrSTA@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 <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@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