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

From Tom Lane
Subject Re: Patch for Improved Syntax Error Reporting
Date
Msg-id 10603.996690793@sss.pgh.pa.us
Whole thread Raw
In response to Patch for Improved Syntax Error Reporting  (Neil Padgett <npadgett@redhat.com>)
List pgsql-patches
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
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
(b) it becomes essentially useless when the input query exceeds a few
lines in size.

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.

In any case, the limiting factor is not the parser change, which is
trivial, but our ability/willingness to change the on-the-wire protocol
to allow error reports to contain multiple components.  There are some
other useful things that could be done once we did that.  Again, I'd
recommend trawling the archives for a bit.

            regards, tom lane

pgsql-patches by date:

Previous
From: "Serguei Mokhov"
Date:
Subject: Re: Re: libpq.pot -> ru.po : Russian - Cyrillic - KOI8-R
Next
From: Paul Ramsey
Date:
Subject: contrib/postgis spatial extensions