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
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() |