Thread: BUG #13832: Syntax errors are extremely unfriendly

BUG #13832: Syntax errors are extremely unfriendly

From
tdhutt@gmail.com
Date:
The following bug has been logged on the website:

Bug reference:      13832
Logged by:          Tim
Email address:      tdhutt@gmail.com
PostgreSQL version: 9.3.5
Operating system:   Linux
Description:

When you have a syntax error in PostgreSQL (or MySQL for that matter) you
get a message like this:

> ERROR: syntax error at or near "FROM"
>   Position: 8

This is not very user-friendly to put it mildly! Compare this with Clang's
error messages (http://clang.llvm.org/diagnostics.html) which give you the
exact location of the error, and also what was expected, and even
suggestions to fix it!

Re: BUG #13832: Syntax errors are extremely unfriendly

From
Tom Lane
Date:
tdhutt@gmail.com writes:
> When you have a syntax error in PostgreSQL (or MySQL for that matter) you
> get a message like this:
>> ERROR: syntax error at or near "FROM"
>> Position: 8
> This is not very user-friendly to put it mildly!

Well, at least some of that is on the head of whatever client-side
software you're using.  psql, for example, produces an error cursor
like this:

regression=# select * from from tab;
ERROR:  syntax error at or near "from"
LINE 1: select * from from tab;
                      ^

> Compare this with Clang's
> error messages (http://clang.llvm.org/diagnostics.html) which give you the
> exact location of the error, and also what was expected, and even
> suggestions to fix it!

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,
eg in PG 9.5 you might get something like this for a misspelled column
name:

regression=# select unnique1 from tenk1;
ERROR:  column "unnique1" does not exist
LINE 1: select unnique1 from tenk1;
               ^
HINT:  Perhaps you meant to reference the column "tenk1.unique1".

            regards, tom lane

Re: BUG #13832: Syntax errors are extremely unfriendly

From
Tim Hutt
Date:
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?
On 24 Dec 2015 16:11, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:

> tdhutt@gmail.com writes:
> > When you have a syntax error in PostgreSQL (or MySQL for that matter) you
> > get a message like this:
> >> ERROR: syntax error at or near "FROM"
> >> Position: 8
> > This is not very user-friendly to put it mildly!
>
> Well, at least some of that is on the head of whatever client-side
> software you're using.  psql, for example, produces an error cursor
> like this:
>
> regression=# select * from from tab;
> ERROR:  syntax error at or near "from"
> LINE 1: select * from from tab;
>                       ^
>
> > Compare this with Clang's
> > error messages (http://clang.llvm.org/diagnostics.html) which give you
> the
> > exact location of the error, and also what was expected, and even
> > suggestions to fix it!
>
> 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,
> eg in PG 9.5 you might get something like this for a misspelled column
> name:
>
> regression=# select unnique1 from tenk1;
> ERROR:  column "unnique1" does not exist
> LINE 1: select unnique1 from tenk1;
>                ^
> HINT:  Perhaps you meant to reference the column "tenk1.unique1".
>
>                         regards, tom lane
>

Re: BUG #13832: Syntax errors are extremely unfriendly

From
Tom Lane
Date:
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

Re: BUG #13832: Syntax errors are extremely unfriendly

From
John McKown
Date:
On Mon, Dec 28, 2015 at 2:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> 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 Biso=
n
> >> 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
>

=E2=80=8BI don't know what you've looked at for the auto-complete, but I ra=
n across
this example which uses GNU readline:
http://cc.byexamples.com/2008/06/16/gnu-readline-implement-custom-auto-comp=
lete/
=E2=80=8B



--=20
Computer Science is the only discipline in which we view adding a new wing
to a building as being maintenance -- Jim Horning

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones =3D 1 Megaphone

Maranatha! <><
John McKown

Re: BUG #13832: Syntax errors are extremely unfriendly

From
Thomas Kellerer
Date:
tdhutt@gmail.com schrieb am 24.12.2015 um 11:44:
> The following bug has been logged on the website:
>
> Bug reference:      13832
> Logged by:          Tim
> Email address:      tdhutt@gmail.com
> PostgreSQL version: 9.3.5
> Operating system:   Linux
> Description:
>
> When you have a syntax error in PostgreSQL (or MySQL for that matter) you
> get a message like this:
>
>> ERROR: syntax error at or near "FROM"
>>    Position: 8
>
> This is not very user-friendly to put it mildly! Compare this with Clang's
> error messages (http://clang.llvm.org/diagnostics.html) which give you the
> exact location of the error, and also what was expected, and even
> suggestions to fix it!

Actually I think Postgres has one of the best implementations of error messages.

Which one of the following:

    http://www.sql-workbench.net/comparison/why_error_messages_matter.html

do you find more user friendly?

Re: BUG #13832: Syntax errors are extremely unfriendly

From
Alvaro Herrera
Date:
John McKown wrote:

> ​I don't know what you've looked at for the auto-complete, but I ran across
> this example which uses GNU readline:
> http://cc.byexamples.com/2008/06/16/gnu-readline-implement-custom-auto-complete/
> ​

We have that already:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/psql/tab-complete.c;hb=HEAD
Tom's point was to get Bison to cooperate so that we can auto-generate
that file instead of having to program the completions ourselves -- and
that the problem of getting Bison to give reasonable syntax error
messages is very similar to that of Bison providing possible
completions.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services