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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
