Re: Better handling of parse errors - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: Better handling of parse errors |
Date | |
Msg-id | 200208140521.g7E5LYu01219@candle.pha.pa.us Whole thread Raw |
In response to | Re: Better handling of parse errors (Gavin Sherry <swm@linuxworld.com.au>) |
List | pgsql-hackers |
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
pgsql-hackers by date: