Thread: BUG #13832: Syntax errors are extremely unfriendly
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!
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
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 >
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
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
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?
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