Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.9.3/8.9.3) with ESMTP id KAA78721 for ; Wed, 28 Jul 1999 10:05:36 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA09681; Wed, 28 Jul 1999 10:04:20 -0400 (EDT) To: Tim Allen cc: pgsql-interfaces@hub.org Subject: Re: [INTERFACES] libpq problem (really libpq feature request) In-reply-to: Your message of Wed, 28 Jul 1999 14:25:55 +1000 (EST) Date: Wed, 28 Jul 1999 10:04:20 -0400 Message-ID: <9679.933170660@sss.pgh.pa.us> From: Tom Lane Tim Allen 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 (got error "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