Dave Page <dpage@vale-housing.co.uk> writes:
> However, pgAdmin does pretty much just the reformatting you've suggested,
> including stripping of comments (well that's in the new codebase anyway),
> so:
> -- Simple Query
> SELECT
> oid,
> relname
> FRUM
> pg_class
> becomes:
> SELECT oid, relname FRUM pg_class
> Giving the error
> ERROR: parser: parse error at or near 'frum':
> SELECT oid, relname FRUM pg_class
> ^
> Which would still be useful of course.
Yes, but on that size of query you hardly need a syntax error pointer
anyway. Consider what happens when the query is several thousand
characters long and the error message wraps across several dozen lines
(as does the spaces-and-caret pointer line). Now you really *need* that
error pointer, but good luck making any use of what's displayed :-(
Another reason why the simplistic approach is not all that useful is
that the reformatting might itself be or mask the problem. Suppose I
fat-finger my query so that I have an accidentally unterminated comment,
or the code recognizes a comment where I didn't intend one. The error
message produced by the backend will omit the parts of the query that
the client code thought were comments, which is likely to make it harder
not easier for me to figure out what I did wrong --- not least because
it eliminates cues I might otherwise use to figure out which part of a
large query string is being complained about.
Basically, upgrading syntax-error behavior to something useful will take
some cooperation from the client side as well as the backend. IMHO we
shouldn't dumb down our ambitions to be merely what can be implemented
without any client cooperation.
regards, tom lane
