Proposed patch for error locations

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-patches(at)postgreSQL(dot)org
Subject: Proposed patch for error locations
Date: 2006-03-12 17:37:35
Message-ID: 5114.1142185055@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces pgsql-patches

The attached WIP patch improves the parser so that cursor positions can be
attached to many errors reported during parse analysis, such as complaints
about nonexistent columns or functions. This is along the lines proposed
in my rant here:
http://archives.postgresql.org/pgsql-patches/2006-02/msg00234.php
to wit, that we make use of bison's "locations" feature to track token
positions in the grammar, and add locations to raw parse tree nodes as
needed.

Some examples of what it can do:

regression=# select unique1,unique2,tem,hundred from tenk1 t;
ERROR: column "tem" does not exist at character 24
LINE 1: select unique1,unique2,tem,hundred from tenk1 t;
^
regression=# select unique1+unique2,ten+hundred,thousand+stringu1 from tenk1;
ERROR: operator does not exist: integer + name at character 44
HINT: No operator matches the given name and argument type(s). You may need to add explicit type casts.
LINE 1: select unique1+unique2,ten+hundred,thousand+stringu1 from te...
^

These examples are perhaps not all that exciting, but in a complex SQL
statement extending over dozens of lines I think it's really important
to be able to do this.

I haven't gone further than making it finger the locations of bogus column
references, operators, and functions --- it's probably worth improving
TypeCast and maybe a few other raw-parse-tree constructs too. Another thing
that needs to be looked at is using the mechanism to locate statement
boundaries, which was the starting-point of the thread mentioned above.

One thing I'm noticing already is that the addition of "at character N"
to a lot of these messages isn't an improvement. In psql it's certainly
redundant with the error-cursor display. As I recall, we include that string
in the primary message text to improve usability with poorer application APIs
that might only show the primary error message to the user. I'm thinking
maybe it's time to expect those client libraries to do better. Any thoughts
about that?

Any comments in general?

regards, tom lane

Attachment Content-Type Size
error-position-1.patch.gz application/octet-stream 18.0 KB

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Michael Glaesemann 2006-03-13 07:42:59 Re: Proposed patch for error locations
Previous Message Tom Lane 2006-03-12 16:18:54 Re: Receiving SIGPIPE for PQfinish(<broken-connection>)

Browse pgsql-patches by date

  From Date Subject
Next Message Volkan YAZICI 2006-03-12 17:59:10 Re: psql patch: new host/port without leaving session
Previous Message Tatsuo Ishii 2006-03-12 01:19:49 Re: [PATCHES] pg_freespacemap question