Thread: PGRES_FATAL_ERROR from queries in transaction abort state?

I am maintaining code that uses libpq, and takes PGRES_FATAL_ERROR to
mean the database connection can no longer be used.  However, this
does not appear to be true in all cases.  I have found that
PGRES_FATAL_ERROR is returned by all queries within a transaction
after any previous query fails.  Unfortunately, I have no good way to
distinguish this situation (which merely requires a ROLLBACK) from an
actual fatal error.  I don't want to parse the text from
PQresultErrorMessage(), because I don't believe it's guaranteed to
remain consistent between versions and locales.  Is there another way
to tell the difference?

Why isn't PGRES_NONFATAL_ERROR returned for queries in an aborted
transaction state?  PGRES_FATAL_ERROR seems like a lie, since the
error is not fatal.

Forest Wilkinson <lyris-pg@tibit.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

>> 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.

Okay.  What does it mean?

>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.

In that case, wouldn't PGRES_NONFATAL_ERROR be a more appropriate
choice for queries that fail due to an aborted transaction?  I can't
think of how this condition could be considered fatal.

>AFAICS the *only* case where you get
>PGRES_NONFATAL_ERROR is when you pass a null PGresult pointer to
>PQresultStatus(),

I got one today by passing ";" to PQexec().