Re: BUG #13832: Syntax errors are extremely unfriendly
От | Tom Lane |
---|---|
Тема | Re: BUG #13832: Syntax errors are extremely unfriendly |
Дата | |
Msg-id | 24516.1451333022@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #13832: Syntax errors are extremely unfriendly (Tim Hutt <tdhutt@gmail.com>) |
Ответы |
Re: BUG #13832: Syntax errors are extremely unfriendly
|
Список | pgsql-bugs |
Tim Hutt <tdhutt@gmail.com> writes: > On 24 Dec 2015 16:11, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: >> As far as raw syntax errors go, we're pretty much limited by what Bison >> will do; we're unlikely to implement our own parser from scratch just >> to improve this. We do go to considerable lengths for semantic errors... > Ah OK I guess this is an issue with Bison - theoretically it should be able > to say what it expects when it gets an invalid token right? You would think. I've experimented with Bison's %error-verbose directive, but if anything its results are worse than doing nothing: it seems to mention only a rather randomly-chosen subset of the possible continuations. (That seems to be related to their decision to put a fairly small hard limit on the length of their error messages, but even allowing for that, what you get seems pretty random.) It's also depressingly concrete; instead of something useful like "expected a table name here", you get "expected IDENT or ABORT or ABSOLUTE or (all possible unreserved keywords...) here", or at least that's what you would get if not for the aforesaid problem. There's been some recent chat in the PG mailing lists about whether we could extract tab-completion logic from the grammar specification, which is sort of related to this issue. We've not gotten far with that idea unfortunately. regards, tom lane
В списке pgsql-bugs по дате отправления: