Hello Tom,
> I concur with Fabien's analysis: we report the FATAL message from
> the server during the first PQgetResult, and then the second call
> discovers that the connection is gone and reports "server closed
> the connection unexpectedly". Those are two independent events
> (in libpq's view anyway) so reporting them separately is correct,
> or at least necessary unless you want to engage in seriously
> major redesign and behavioral changes.
>
> It is annoying that some of the text is duplicated in the second
> report, but in the end that's cosmetic, and I'm not sure we can
> improve it without breaking other things. In particular, we
> can't just think about what comes back in the PGgetResult calls,
> we also have to consider what PQerrorMessage(conn) will report
> afterwards. So I don't think that resetting conn->errorMessage
> during a PQgetResult series would be a good fix.
>
> An idea that I don't have time to pursue right now is to track
> how much of conn->errorMessage has been read out by PQgetResult,
> and only report newly-added text in later PQgetResult calls of
> a series, while PQerrorMessage would continue to report the
> whole thing. Buffer resets would occur where they do now.
>
> It'd probably be necessary to make a user-visible PQgetResult
> that becomes a wrapper around PQgetResultInternal, because
> internal callers such as PQexecFinish will need the old behavior,
> or at least some of them will.
I agree that the message reset is not convincing, but it was the only way
to get the expected behavior without changing the existing functions.
I see two paths:
(1) keep the duplicate message in this corner case.
(2) do the hocus pocus you suggest around PQerrorMessage and PQgetResult
to work around the duplication, just for this corner case.
I'd tend to choose (1) to keep it simple, even if (2) is feasible.
--
Fabien.
