Josh Berkus <josh@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