pg.ddx.io pgsql-interfaces@postgresql.org mailing list archivehelp / color / mirror / Atom feed
PGRES_FATAL_ERROR from queries in transaction abort state? 3+ messages / 2 participants [nested] [flat]
* PGRES_FATAL_ERROR from queries in transaction abort state? @ 2003-05-22 20:58 Forest Wilkinson <lyris-pg@tibit.com> 0 siblings, 1 reply; 3+ messages in thread From: Forest Wilkinson @ 2003-05-22 20:58 UTC (permalink / raw) To: pgsql-interfaces 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. ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: PGRES_FATAL_ERROR from queries in transaction abort state? @ 2003-05-23 00:06 Tom Lane <tgl@sss.pgh.pa.us> parent: Forest Wilkinson <lyris-pg@tibit.com> 0 siblings, 1 reply; 3+ messages in thread From: Tom Lane @ 2003-05-23 00:06 UTC (permalink / raw) To: Forest Wilkinson <lyris-pg@tibit.com>; +Cc: pgsql-interfaces 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 ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: PGRES_FATAL_ERROR from queries in transaction abort state? @ 2003-05-23 00:23 Forest Wilkinson <lyris-pg@tibit.com> parent: Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 3+ messages in thread From: Forest Wilkinson @ 2003-05-23 00:23 UTC (permalink / raw) To: 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(). ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2003-05-23 00:23 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2003-05-22 20:58 PGRES_FATAL_ERROR from queries in transaction abort state? Forest Wilkinson <lyris-pg@tibit.com> 2003-05-23 00:06 ` Tom Lane <tgl@sss.pgh.pa.us> 2003-05-23 00:23 ` Forest Wilkinson <lyris-pg@tibit.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox