On 04/16/2015 04:36 PM, Tom Lane wrote:
> You could imagine teaching yyerror() to have some SQL-specific knowledge
> that it could apply by comparing the current lookahead token to the
> current parse state stack ... but neither of those things are exposed
> to it by Bison. We could probably get the lookahead token indirectly
> by inspecting the lexer's state, but it's not clear that's enough to
> do much. In this particular example, that would mean showing the exact
> same hint whenever a syntax error is reported at an OVER token; and
Yeah, and that's what we *don't* want to do. That's why I was wondering
if it was even possible to figure out the "extra syntax" case.
> I'm afraid that it'd be mighty hard to write a hint for that that
> wouldn't frequently do more harm than good. (Note in particular that
> since OVER, FILTER, and WITHIN are unreserved keywords, they might be
> used as simple column/table/function names.)
No kidding. Heck, I just spent 1/2 hour figuring out a bug which was
actually caused by the fact that a user created a view called "mode".
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com