Re: Patch for Improved Syntax Error Reporting

> 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

Tom, it is hard to imagine how they would even find relevant stuff on
this issue.  The TODO.detail item is very vague.  Would they start
searching for keywords in the mailing list search engine?  Not sure what
keywords they would even use.

In fact, their solution is an improvement over what is in
TODO.detail/yacc now.

> 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. . .

The whole internet seems slow today.  I think it is that Code Red worm.

> > 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.

I know some people like a client-independent way of displaying errors,
but I like the direct approach of this patch, returning a string with
the error line highlighted and the location marked.  I don't want to
push added complexity into the client, especially when we don't even
have a client who has this need yet.

IMHO, I am starting to see a lot of over-engineering demands made of
these patches.  I think it is wasting time and is of little value to
average PostgreSQL users.  Of course, others may disagree, but that is
my opinion.

So, my vote is to accept the patch as-is.  When we have need for more
complex reporting, we can add it.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026