pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tim Allen <tim@proximity.com.au>
Cc: pgsql-interfaces@hub.org
Subject: Re: [INTERFACES] libpq problem (really libpq feature request)
Date: Wed, 28 Jul 1999 10:04:20 -0400
Message-ID: <9679.933170660@sss.pgh.pa.us> (raw)
In-Reply-To: <Pine.LNX.4.10.9907281414020.26149-100000@bee.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 (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



view thread (4+ messages)  latest in thread

Message-ID: <9679.933170660@sss.pgh.pa.us>
Permalink:  ../9679.933170660@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/9679.933170660@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-interfaces@postgresql.org
  Cc: tgl@sss.pgh.pa.us, tim@proximity.com.au, pgsql-interfaces@hub.org
  Subject: Re: [INTERFACES] libpq problem (really libpq feature request)
  In-Reply-To: <9679.933170660@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox