Re: BUG #13832: Syntax errors are extremely unfriendly

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tim Hutt <tdhutt(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #13832: Syntax errors are extremely unfriendly
Date: 2015-12-28 20:03:42
Message-ID: 24516.1451333022@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tim Hutt <tdhutt(at)gmail(dot)com> writes:
> On 24 Dec 2015 16:11, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message John McKown 2015-12-28 20:15:52 Re: BUG #13832: Syntax errors are extremely unfriendly
Previous Message alain.laporte12345 2015-12-28 17:32:29 BUG #13837: Files in pg_committs not deleted