From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Subject: | Re: libpq PQresultErrorMessage vs PQerrorMessage API issue |
Date: | 2021-02-16 15:15:21 |
Message-ID: | 2368081.1613488521@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com> writes:
> This morning for the the umpteenth time I saw:
> some error message: [blank here]
> output from a libpq program.
> That's because passing a NULL PGresult to PQgetResultErrorMessage() returns
> "". But a NULL PGresult is a normal result from PQexec when it fails to
> submit a query due to an invalid connection, when PQgetResult can't get a
> result from an invalid connection, etc.
How much of this is due to programmers not bothering to check whether
PQconnectXXX succeeded? I do not think we need to go far out of our
way to cope with that scenario.
The idea of having a static PGresult that we can hand back to denote
out-of-memory scenarios is kind of cute. But again, I wonder how
often the situation comes up in the real world. It might be worth
doing just to have a more consistent API spec, though. Particularly
for PQgetResult, where a NULL result has a defined, non-error meaning.
In general I doubt there's enough of a problem here to justify
inventing new or different APIs. But if we can sand down some
rough edges without doing that, let's have a look.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | chenhj | 2021-02-16 15:15:36 | Re: [Proposal] Page Compression for OLTP |
Previous Message | Tomas Vondra | 2021-02-16 15:04:44 | Re: POC: postgres_fdw insert batching |