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

On 2000-02-24, Jeroen van Vianen mentioned:

> At 11:12 22-02-00 -0500, Tom Lane wrote:

> >I'd be inclined to say that the location info should be imbedded as
> >text in the existing textual error message, rather than trying to add
> >a separate message with a machine-readable location value.

> Isn't it possible to get this kind of information from a call to a new API 
> struct errorinfo *  PQerrorInfo(conn) where the struct contains info about 
> the error message, location and code, rather than a call to 
> PQerrorMessage(conn) ?

IMHO, the use of error messages in PostgreSQL has a big conceptual
problem. It's only too tempting to write elog(ERROR, "I don't know what to
do now.") anywhere and any time. This is very convenient for the
developers but not very nice for client applications that want to
recognize, categorize, and recover from errors. There isn't even a clean
separation of perfectly normal user-level errors ("referential integrity
violation") and internal errors (bugs) ("can't attach node 718 to
T_ParseNodeFoo"). Sure, there's FATAL, but it's not always appropriate.

Chapter 22 of SQL92 defines error codes ("SQLSTATE") for (presumably)
every condition that could come up. It has classes and subclasses and
its code space is extensible. It would be very nice if we could classify
error messages in the backend according to that list and, say, do an
error(PGE_TRIGGERED_DATA_CHANGE_VIOLATION);

instead. The frontend could then call PQsqlstate(connection) to get this
code, or it could call something equivalent to strerror that would convert
this code to a string (potentially language-dependent even). If someone
wants to communicate an internal yet non-fatal error, there would be a
special code reserved for it, telling the client application that it might
as well forget about it. Legacy applications could still call
PQerrorMessage which would interally call the above two.

A necessary extension to the above would be a way to pass along supportive 
data. The tricky part will be to figure out a syntax that is not too
cumbersome, not too restrictive, and encourages help by the compiler. For
example,
error(PG_PARSE_ERROR, 2345)error(PG_PARSE_ERROR(2345))error(PG_PARSE_ERROR, errorIntData(2345))error(PG_INTERNAL,
errorStrData("I'mway lost"))
 

or something hopefully much better. If error() is made a macro, then we
could include file and line number and have some libpq accessor function
for them. Somehow, the client should also be able to access the "2345"
directly.

In any case, I believe that the actual error message string should be
assembled in the front-end. I'm not too fond of the idea of letting
clients parse out the interesting parts of an error out of a blob of text.

Comments? Anyone interested? This would be very dear to my heart so I'd be
very willing to spend a lot of time on it.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden