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

From Dave Page
Subject RE: Patch for Improved Syntax Error Reporting
Date
Msg-id 8568FC767B4AD311AC33006097BCD3D61A2D6A@woody.vale-housing.co.uk
Whole thread Raw
In response to Patch for Improved Syntax Error Reporting  (Neil Padgett <npadgett@redhat.com>)
Responses Re: Patch for Improved Syntax Error Reporting  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches

> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: 01 August 2001 22:23
> To: Bruce Momjian
> Cc: Tom Lane; Neil Padgett; pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] Patch for Improved Syntax Error Reporting
>
>
> > > > In fact, their solution is an improvement over what is in
> > > > TODO.detail/yacc now.
> > >
> > > Agreed, the idea of pulling out just the one line is an
> improvement
> > > over the last patch.  It's still going down the wrong
> path though.
> > > We should be empowering client apps to highlight syntax errors
> > > properly, not presenting edited info in a way that might
> be useful
> > > to humans but will be unintelligible to programs.  If we go that
> > > route, it will be harder to do the right thing later.
> > >
> > > > 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.
> > >
> > > pgAdmin, phpAdmin, pgaccess, and friends don't count?  We
> have GUI
> > > front ends *today*, you know.
> >
> > But how do they display error messages now?  Can't they
> just continue
> > doing that with this new code?  Do we want to make them
> code their own
> > error handling, and for what little benefit?  Let them
> figure out how
> > to display the error in fixed-width font and be done with it.  I am
> > sure they have bigger things to do than colorize error locations.
>

Apologies for not responding to the original message, I only seem to have
bits of this thread :-(

In the case of pgAdmin, it displays the error messages as returned by the
backend. I have no desire to start maintaining my own list of error
codes/messages, especially as those returned by the backend are generally
user friendly, and I certainly don't want to start parsing user supplied SQL
statements myself - I'd rather leave that to the real parser.

Personally I would welcome syntax error messages in the form Neil's original
patch supplies.

Regards, Dave.

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Revised Patch to allow multiple table locks in "Unison"
Next
From: Dave Page
Date:
Subject: RE: Patch for Improved Syntax Error Reporting