Re: Better handling of parse errors - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Better handling of parse errors
Date
Msg-id 19999.1028646088@sss.pgh.pa.us
Whole thread Raw
In response to Better handling of parse errors  (Gavin Sherry <swm@linuxworld.com.au>)
Responses Re: Better handling of parse errors  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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 sayparse error at end of input
when that's the case, rather than the rather uselessparse 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CVS sources doesn't compiles
Next
From: Alvaro Herrera
Date:
Subject: Re: Proposal for psql wildcarding behavior w/schemas