Skip site navigation (1) Skip section navigation (2)

Re: [INTERFACES] libpq problem (really libpq feature request)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tim Allen <tim(at)proximity(dot)com(dot)au>
Cc: pgsql-interfaces(at)hub(dot)org
Subject: Re: [INTERFACES] libpq problem (really libpq feature request)
Date: 1999-07-28 14:04:20
Message-ID: 9679.933170660@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-interfaces
Tim Allen <tim(at)proximity(dot)com(dot)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

pgsql-interfaces by date

Next:From: Tom LaneDate: 1999-07-28 14:14:20
Subject: Re: [INTERFACES] libpq problem (really libpq feature request)
Previous:From: Herouth MaozDate: 1999-07-28 12:01:11
Subject: Re: [INTERFACES] (Yet another) unable to connect w/ JDBC via hostname

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group