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