BUG #13832: Syntax errors are extremely unfriendly

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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

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:

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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

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 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

​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/
​

--
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 = 1 Megaphone

Maranatha! <><
John McKown

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?

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

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

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs