Re: Better handling of parse errors
От | Bruce Momjian |
---|---|
Тема | Re: Better handling of parse errors |
Дата | |
Msg-id | 200208140509.g7E59GQ00419@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Better handling of parse errors (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Better handling of parse errors
|
Список | pgsql-hackers |
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 по дате отправления: