At 20:03 20-02-00 -0500, Tom Lane wrote:
>I do see a potential problem with this patch that's not related to
>portability questions; it is that you're assuming that the lexer's
>furthest penetration into the source text is a good place to point
>at for parser errors. That may not be true always. In particular,
>I've been advocating solving some other problems by inserting a
>one-token lookahead buffer between the parser and the lexer. If that
>happens then you'd be off by (at least) one token in some cases.
That's true, but the '*' indicator might at least indicate the approximate
location of the error. I'm not aware of many (programming) languages that
are able to indicate the error at the correct location all the time, anyway.
>I think the way that this sort of thing is customarily handled in
>"real" compilers is that each token carries along an indication of
>just where it was found in the source, and then error messages can
>finger the right place without making assumptions about synchronization
>between different phases of the scanning/parsing process. That might
>be more work than we can justify for SQL queries; not sure.
True, but requires a lot more work.
>BTW, I think that the immediate problem of generating a good error
>message for unterminated comments and literals could be solved in other
>ways. This patch or something like it might be cool anyway, but you
>should bear in mind that printing out a query and then a marker that's
>supposed to line up with something in the query doesn't always work
>all that well. Consider a query that's several dozen lines long,
>such as a large table definition. If we had more control over the
>user interface and could highlight the offending token directly,
>I'd be more excited about doing something like this. (Actually, you
>could partially address that problem by only printing one line's worth
>of query text leading up to the error marker point. It would still be
>tricky to get it right in the presence of newlines, tabs, etc.)
I try to make a good guess at where the location of the error is, but am
hesitant to only print a few tokens near the error locations, as you won't
be able to know where the error was found in complex queries or table
definitions. Please try with more complex queries and tell me what you think.
Jeroen