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