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