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