Josh Berkus <j...@agliodbs.com> writes: > ERROR: syntax error at or near "FILTER" > LINE 4: count(*)::INT FILTER (WHERE valid) as valid_count,
> The error is right, that's invalid syntax. I can't insert a ::INT > between the aggregate() and FILTER. However, the error message is also > rather confusing to the user; they're likely to look for their mistake > in the wrong place. The same goes for WITHIN GROUP (and OVER, too, I > think). > Is there some kind of possible HINT we could add to make this easier to > debug? Probably not; or at least, IMO it would be a fundamental misjudgment to go in with the idea of improving this one single case. It'd be cool if we could improve reporting of syntax errors in general, though. Unfortunately Bison doesn't provide a whole heckuva lot of support for that. The only simple thing it offers is %error-verbose, which I've experimented with in the past and come away with the impression that it'd be completely useless for most people :-(. It seems to basically add information about which tokens would be valid next at the point of the error report. That isn't any help for the sort of user conceptual error you're talking about here. 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 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.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers