On 24 June 2013 03:50, Tom Lane <t...@sss.pgh.pa.us> wrote: > David Fetter <da...@fetter.org> writes: >> On Sun, Jun 23, 2013 at 07:44:26AM -0700, Kevin Grittner wrote: >>> 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? >
The flip side is that the error message you get if you don't realise a word is now reserved is not exactly useful: "Syntax error at or near xxx". I don't know of any way to improve that though. > Of the alternatives discussed so far, I don't really like anything > better than adding another special case to base_yylex(). Robert opined > in the other thread about RESPECT NULLS that the potential failure cases > with that approach are harder to reason about, which is true, but that > doesn't mean that we should accept failures we know of because there > might be failures we don't know of. > > One thing that struck me while thinking about this is that it seems > like we've been going about it wrong in base_yylex() in any case. > For example, because we fold WITH followed by TIME into a special token > WITH_TIME, we will fail on a statement beginning > > WITH time AS ... > > even though "time" is a legal ColId. But suppose that instead of > merging the two tokens into one, we just changed the first token into > something special; that is, base_yylex would return a special token > WITH_FOLLOWED_BY_TIME and then TIME. We could then fix the above > problem by allowing either WITH or WITH_FOLLOWED_BY_TIME as the leading > keyword of a statement; and similarly for the few other places where > WITH can be followed by an arbitrary identifier. > > Going on the same principle, we could probably let FILTER be an > unreserved keyword while FILTER_FOLLOWED_BY_PAREN could be a > type_func_name_keyword. (I've not tried this though.) > I've not tried either, but wouldn't that mean that "SELECT * FROM list_filters() filter" would be legal, whereas "SELECT * FROM list_filters() filter(id, val)" would be a syntax error? If so, I don't think that would be an improvement. 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
