Re: A plan to improve error messages with context, hint and details.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A plan to improve error messages with context, hint and details.
Date: 2004-03-04 21:04:05
Message-ID: 28690.1078434245@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
> (1) Lexical/syntax error source localisation

> An extract of the offending source must be shown if possible along syntax
> error messages.

You would do well to go to the archives and read some of the previous
discussion of these issues. In particular, we determined that the
appropriate place for this sort of thing is on the client side, not in
the backend. Only the client knows what is a reasonable way to mark the
error position. (Think about GUI clients vs command line clients,
different size windows, etc.) As of 7.4 we do send back a cursor offset
as one of the fields of an error message, and I think the next step is
to make the client-side code do something with that.

> All generated error messages, especially from the parser, should be
> assorted with a HINT to help the user, if possible. Something like:
> HINT: table name expected

I think the odds of doing anything very successful in the way of syntax
hints are small. The cases where you can produce a reliable hint (ie,
one that's not likely to be misleading) are not very interesting.
I don't think your idea of relying on the last parser state will work
well, because the parser frequently is off a word or two as to the
actual location of the error (since it will do its best to make sense of
what it sees, until there is no remaining possibility of a successful
parse). That will be enough to cause you to deliver the wrong hint,
and a wrong hint is worse than none.

ISTM that client-side code that pops up the syntax summary for the
command would probably accomplish far more, for far less work.

We do have some hints for semantic errors, and adding more isn't a bad
project, but you still have the same hazard of whether you can deliver
useful hints.

> ... in the processing of the command. The problem is different because it
> occurs in functions that can be called from quite different contexts, and
> the context is not really known to the function. Thus when the error
> occurs in the function, it cannot provide a useful context. As none is
> provided, the user must guess...

I am not understanding what you have against the existing error context
stack mechanism. Certainly it could be used in more places than it is,
but why do you feel a need to build a separate one?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lawrence E. Smithmier, Jr. 2004-03-04 21:46:03 Re: [HACKERS] Tablespaces
Previous Message Robert Treat 2004-03-04 20:24:53 Re: [HACKERS] Regression tests on Nintendo Game Cube