RE: Patch for Improved Syntax Error Reporting

> -----Original Message-----
> From: Fernando Nasser [mailto:fnasser@cygnus.com]
> Sent: 01 August 2001 22:34
> To: Bruce Momjian
> Cc: Tom Lane; Neil Padgett; pgsql-patches@postgresql.org
> Subject: Re: [PATCHES] Patch for Improved Syntax Error Reporting
>
>
> Bruce Momjian wrote:
> >
> > > > > 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.
> >
> > A bigger question is that if we decide to output just offset
> > information in the message, we have to be sure _all_ the
> clients can
> > interpret it or the syntax information is confusing.  Are
> we prepared
> > to get all the clients update at the same time we add the feature?
> > Seems we should go with a simple solution now and add later.
> >
>
> If instead of printing:
>
> ERROR: A parse error near "foo"
>
> we print
>
> ERROR: A parse error near "foo" (index=10)
>
> it should not affect any of the existing clients.
> For the clients, this will be just text as before and they
> will print it as received.  If some client wants, it may look
> for the index information and do whatever is convenient for
> that interface (as an enhancement).
>
> So I think this option is backward compatible.

I disagree. In pgAdmin's case, if the user enters an SQL query, pgAdmin will
rewrite it to remove any formatting that the user has entered before it's
sent to the backend. This means that the query sent may (== often is)
shorter than the query entered by the user where carriage returns etc. have
been removed, hence the index value would just be confusing to the user as
it may well be wrong.

Regards, Dave.