Re: Better handling of parse errors
От | Tom Lane |
---|---|
Тема | Re: Better handling of parse errors |
Дата | |
Msg-id | 19999.1028646088@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Better handling of parse errors (Gavin Sherry <swm@linuxworld.com.au>) |
Ответы |
Re: Better handling of parse errors
|
Список | 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 по дате отправления: