Re: Better handling of parse errors

I don't think anyone will mind, but you can throw a message to 'general'
just to be sure.

---------------------------------------------------------------------------

Gavin Sherry wrote:
> Bruce,
> 
> I was working on this on the train this morning. There are a few
> possibilities I'd like to look at before I submit another patch.
> 
> Before I do, there is one important question that I didn't raise when I
> submitted the first patch (which was only a proof of concept kind of
> patch). Namely: do we want to modify every 7.2 error message? Many people
> have written error message parsers into their applications to make up for
> the fact that Postgres doesn't use error codes or issue 'standardised'
> error messages.
> 
> Is this going to annoy people too much? Should it be delayed until we have
> SQL99 diagnostics/error codes?
> 
> Gavin
> 
> On Wed, 14 Aug 2002, Bruce Momjian wrote:
> 
> > 
> > Gavin, have you answered these issues brought up about the patch?
> > 
> > ---------------------------------------------------------------------------
> > 
> > Tom Lane wrote:
> > > Gavin Sherry <swm@linuxworld.com.au> writes:
> > > > Attached is a small patch to scan.l for consideration. It hands
> > > > yyerror() the position in the query string of the token which caused a
> > > > parse error.
> > > 
> > > Isn't that the hard way to do it?  Seems like you could just subtract
> > > scanbuf from the error pointer, instead of adding overhead to the basic
> > > lex loop.
> > > 
> > > Things that need to be decided (and documented somewhere):
> > > 
> > > Is the number an offset (counted from 0) or an index (counted from 1)?
> > > Which end of the token does it point at?  Can the message be phrased
> > > so as to make it reasonably clear what the number is?
> > > 
> > > 
> > > A related change I'd been meaning to make is to get it to say
> > >     parse error at end of input
> > > when that's the case, rather than the rather useless
> > >     parse error at or near ""
> > > that you get now.  I'd still be inclined to just say "end of input"
> > > in that case, and not bother with a character count.
> > > 
> > >             regards, tom lane
> > > 
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> > > 
> > 
> > 
> 
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073