| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Forest Wilkinson <lyris-pg(at)tibit(dot)com> |
| Cc: | pgsql-interfaces(at)postgresql(dot)org |
| Subject: | Re: PGRES_FATAL_ERROR from queries in transaction abort state? |
| Date: | 2003-05-23 00:06:27 |
| Message-ID: | 12311.1053648387@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-interfaces |
Forest Wilkinson <lyris-pg(at)tibit(dot)com> writes:
> I am maintaining code that uses libpq, and takes PGRES_FATAL_ERROR to
> mean the database connection can no longer be used.
It has never meant that. Only connection status going to CONNECTION_BAD
would mean that.
> Why isn't PGRES_NONFATAL_ERROR returned for queries in an aborted
> transaction state?
I think that the original design intended the code PGRES_NONFATAL_ERROR
to be used for what we now call a WARNING; but in point of fact it's not
being used at all, because warnings aren't reported through
PQresultStatus. AFAICS the *only* case where you get
PGRES_NONFATAL_ERROR is when you pass a null PGresult pointer to
PQresultStatus(), which in the current code is a pretty dubious choice
(PGRES_EMPTY_QUERY is arguably better).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Forest Wilkinson | 2003-05-23 00:23:45 | Re: PGRES_FATAL_ERROR from queries in transaction abort state? |
| Previous Message | Forest Wilkinson | 2003-05-22 20:58:10 | PGRES_FATAL_ERROR from queries in transaction abort state? |