Craig Ringer <craig.ringer@enterprisedb.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