Re: libpq PQresultErrorMessage vs PQerrorMessage API issue

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

In response to

Browse pgsql-hackers by date

  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