Re: Patch for Improved Syntax Error Reporting - Mailing list pgsql-patches

Tom Lane wrote:
>
> Neil Padgett <npadgett@redhat.com> writes:
> > Attached please find a patch to the input parser that yields better
> > syntax error reporting on parse errors.
>
> This has been discussed before (you guys really should spend more time
> reading the mail list archives) and in fact you are not the first to

I've just read the relevant messages. Though, I do find the list
archives a bit slow for any useful browsing -- can I grab a copy of them
from somewhere? Setting up a mirror might be an idea. . .

> submit essentially this patch.  The major objections to reporting syntax
> problems this way, IIRC, are that (a) it makes unsupportable assumptions
> about what the user interface looks like, for example the assumption
> that the error message will be displayed in a fixed-width font; and

Can you cite a client which does not use a fixed-width font at this
time? I think most I've worked with use one for SQL interaction -- it is
pretty much "the way things are done." I suppose, however, there could
be some clients which display error messages in a dialog box or
something similar, so I do agree that this is something that does need
to be handled, and which the patch doesn't address. See below for a
suggestion for this.

> (b) it becomes essentially useless when the input query exceeds a few
> lines in size.

How so? I grab out the line of interest when reporting the error.

>
> The conclusion we had come to in previous discussion is that the error
> offset ought to be delivered to the client application as a separate
> component of the error report, and the client ought to be responsible
> for doing something appropriate with it --- which might, for example,
> include highlighting the offending word(s) if it's a GUI application
> that has the input query in a window.  psql couldn't do that, but might
> choose to redisplay a few dozen characters around the position of the
> error.

Well, perhaps the error message could be changed to something like this,
with a special string marking the parse error position?

test=# SELECT * FRUM bob;
ERROR:  parser: parse error at or near 'frum':
SELECT * ***FRUM bob;

Or, perhaps better than a magic string:

test=# SELECT * FRUM bob;
ERROR:  parser: parse error at or near 'frum' (index 10)

The latter is probably more useful, though it does place a burden on the
client to format and display an error message. But, the client program
can mark out the error in any way it sees fit. In fact, it could even
leave the raw message in place and still the user will get something
more useful than the current output. No protocol change is required, but
very useful functionality is added.

Neil

--
Neil Padgett
Red Hat Canada Ltd.                       E-Mail:  npadgett@redhat.com
2323 Yonge Street, Suite #300,
Toronto, ON  M4P 2C9