Re: Is there public API to fetch errcode?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Sergey Fukanchik <s(dot)fukanchik(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is there public API to fetch errcode?
Date: 2025-10-12 18:03:22
Message-ID: 30345.1760292202@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Sun, Oct 12, 2025 at 1:27 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> PQresultErrorField(res, PG_DIAG_SQLSTATE) should do, no?

> I believe the call flow is the following - no "res"/result is ever
> constructed:

Hmm ... no, we do construct a PGresult containing the error (including
SQLSTATE), because pqGetErrorNotice3 is what's used to read the
server's error response. But it looks like for a connection-time
failure, PQconnectPoll clears it before returning.

In principle maybe we could keep that around, allowing the application
to do PQgetResult from the failed connection object. Seems like it'd
be a bit of a mess though. Also, given all the logic that's there
to retry different server addresses etc, it's not clear which failure
result to preserve. We sidestep that question so far as the textual
PQerrorMessage output is concerned by concatenating all the failures,
but that's not workable for PGresults.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-10-12 18:09:37 Re: Implementing IF NOT EXISTS clause for all CREATE TYPE variants
Previous Message Alexander Lakhin 2025-10-12 18:00:00 Re: Potential deadlock in pgaio_io_wait()