Sorry, I am an impatient man. I truly appreciate all the responses to my question. Some study of postgres.c from the pgdriver tarball reveals that it is actually intended for the Postgresql errors to go into the traceback. The code to place this information on into the Tcl result stack relies on a two-part error code, ie. an "exception" and the error message. If the exception is not set (which the postgres driver never does), it assumes there's no error message (which is in fact there). The design appears to be based on Oracle, where you have an Oracle error message which can sometimes be useful to look up (and depending on how your Oracle is installed, might be the only thing you have to go on).
Here's a patch to postgres.c to put the PostgreSQL error message onto the Tcl traceback. It works by putting a string into the exception code, so that the DbFail routines will look for the error message.
--- /goose/aolserver/pgdriver-2.0.1/postgres.c Tue Sep 4 12:25:44 2001
+++ postgres.c Tue May 21 14:45:47 2002
@@ -471,15 +471,18 @@
case PGRES_COPY_IN:
case PGRES_NONFATAL_ERROR:
Ns_DStringAppend(nsMsg, PQresultErrorMessage(nsConn->res));
+ strcpy(handle->cExceptionCode, "WARN");
break;
case PGRES_FATAL_ERROR:
Ns_DStringAppend(nsMsg, PQresultErrorMessage(nsConn->res));
+ strcpy(handle->cExceptionCode, "FATAL");
break;
case PGRES_BAD_RESPONSE:
Ns_DStringAppend(nsMsg, "PGRES_BAD_RESPONSE ");
Ns_DStringAppend(nsMsg, PQresultErrorMessage(nsConn->res));
+ strcpy(handle->cExceptionCode, "BAD");
break;
}
}