Re: [PATCHES] Patch for more readable parse error messages

At 00:56 22-02-00 +0100, Peter Eisentraut wrote:
>On 2000-02-20, Jeroen van Vianen mentioned:
>
> > The format of the error messages is changed to:
> >
> > jeroen=# create abc ( a int4, b int4 );
> > ERROR:  parser: parse error at or near "abc":
> > create abc ( a int4, b int4 )
> >         *
>
>I believe this is the wrong approach because it's highly psql specific. If
>you use PHP or JDBC or something not character cell based you will get
>misleading output.
>
>You might want to start thinking about putting a little more information
>into an ERROR than just a text string, such as error codes or
>supplementary information like this. psql could then choose to print a
>star, other interfaces might set the cursor to the specified place, etc.
>Much more flexible.

Good idea. As far as I understand things, libpq uses special datastructures 
to access the error code and message and it's up to the application (psql, 
and others) to do what it wants to do with it (let's say print the error). 
These structures might be enhanced with an error location, but this might 
be breaking things. And my question is how to do this.

Note that this location part is only filled now when yyerror() throws an 
error, but other parts of the backend might use a similar approach. OTOH it 
might be nice then to have every token know its location in the query 
string (as Don suggested), so you might end up with error messages like:

mydb-> select * from t1, t2 where ...
ERROR: table t2 not found:
select * from t1, t2 where ...                  ^

(which may be nice, or not).

What I see now is something like this (for psql):

psql sends a query
psql reads response        if response is error                get error location and find context in which error
occurred               print error message, with error location and context        otherwise                do what it
usedto do
 

and for the other interfaces nothing changes.

This is something I might be able to implement for 7.1.

What do you think?


Jeroen