Обсуждение: Re: [INTERFACES] libpq problem (really libpq feature request)

> Date: Tue, 27 Jul 1999 17:46:28 +0200
> From: "Jonathan davis" <haj@idianet.net>
> 
> >"Jonathan davis" <haj@idianet.net> writes:
> >> with libpq, i can't difference between bad password and server down !!
> >
> >Are you paying attention to PQerrorMessage?
> >
> > regards, tom lane
> >
> I means errors with code (int)

I think Jonathan is alluding (in a rather obtuse manner :-)) to an issue
that is on my wishlist also, namely a more systematic way of identifying
errors. Currently, libpq gives you an error state (no error, nonfatal
error, or fatal error) and an error message. What would be nice is if
there was also some sort of error code (eg an integer) that identified the
exact nature of the problem. And, of course, a published spec of what the
error codes mean. Then it would be much easier for one's program to know
what the error was, and, if possible, do something about it. From my point
of view, there are basically two classes of error - programmer error, and
resource limitation error (eg network problems, disk space problems). The
fundamental difference is that for the latter, the user might be able to
do something about it, whereas for the former, you need to modify the
code. It would be good if a program could deduce which it was without
having to do anything silly and dangerous like trying to parse the error
message.

Tim

-----------------------------------------------
Tim Allen
Proximity Pty Ltd  http://www.proximity.com.au
-----------------------------------------------

Tim Allen <tim@proximity.com.au> writes:
> I think Jonathan is alluding (in a rather obtuse manner :-)) to an issue
> that is on my wishlist also, namely a more systematic way of identifying
> errors. Currently, libpq gives you an error state (no error, nonfatal
> error, or fatal error) and an error message. What would be nice is if
> there was also some sort of error code (eg an integer) that identified the
> exact nature of the problem.

Yes, that is an item on the TODO list, I believe.  The text error
messages are fine for human consumption, but not so great for programs
that want to try to cope with an error.

Aside from the cases you mention, there are "expected errors" that a
program might know about and want to recover from --- for example,INSERT new_record INTO table_with_unique_index;if
(goterror "Cannot insert duplicate key")    UPDATE table_with_unique_index SET data = new_record.data    WHERE key =
new_record.key;
which works until someone decides to spell the error message a little
differently...

However, creating and maintaining the list of message codes is a lot
of very tedious, uninteresting work, and no one so far has had the
fortitude to actually do it.  (One of the deficiencies of the open-
source model is that you can't assign some junior programmer to go do
the tasks no one else wants to do :-(.)  Any volunteers out there?
        regards, tom lane