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
---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match