Re: PGRES_FATAL_ERROR from queries in transaction abort state? - Mailing list pgsql-interfaces

From Forest Wilkinson
Subject Re: PGRES_FATAL_ERROR from queries in transaction abort state?
Date
Msg-id otpqcvgqsa205b6gfut5mdivm08e5ttr78@4ax.com
Whole thread Raw
In response to Re: PGRES_FATAL_ERROR from queries in transaction abort state?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-interfaces
>> 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().




pgsql-interfaces by date:

Previous
From: Tom Lane
Date:
Subject: Re: PGRES_FATAL_ERROR from queries in transaction abort state?
Next
From: "BTS"
Date:
Subject: PREPARE in ECPG