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

From: Jeroen van Vianen <jeroen(at)design(dot)nl>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [PATCHES] Patch for more readable parse error messages
Date: 2000-02-22 09:55:13
Message-ID: 4.2.2.20000222103948.00ac8d10@mail.design.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 used to 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris 2000-02-22 10:09:55 Re: [HACKERS] psql and pager
Previous Message Tom Lane 2000-02-22 06:57:40 Re: [HACKERS] Beta for 4:30AST ... ?