Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Accepting the keyword in such a context seems much harder to me than
> providing a hint. To accept the keyword, you'd need a lot of changes to
> the grammar, but for the hint, you just need some extra code in
> yyerror(). Mind you, if it's a hint, it doesn't need to be 100%
> accurate, so I think you could just always give the hint if you get a
> grammar error at a token that's a reserved keyword.
Unfortunately, while a useful hint doesn't have to be 100% right, it
does have to be a great deal more than 0% right. And what you're
suggesting here would be nearly all noise. For example, if I writeSELECT ORDER BY x;
it is not going to be helpful to be told that ORDER is a reserved word.
It will soon become annoying for that hint to pop up in many contexts
where it's completely inappropriate.
If you could restrict it to only happen in contexts where the *only*
expected token is an identifier, it might be of some use, but I'm
doubtful that yyerror() has that much info.
There is some stuff in the Bison manual about writing "error"
productions, which I've never paid much attention to because it only
seemed to be useful for resychronizing between statements. But maybe
there's something there for this purpose.
> Even if it was easy to accept the keywords when there's no ambiguity, I
> don't think we would want that. Currently, we can extend the syntax
> using existing keywords, knowing that we don't break existing
> applications, but that would no longer be true if reserved keywords were
> sometimes accepted as identifiers.
Good point.
regards, tom lane