Re: Documentation improvement for PQgetResult - Mailing list pgsql-docs

From Tom Lane
Subject Re: Documentation improvement for PQgetResult
Date
Msg-id 18521.1281104418@sss.pgh.pa.us
Whole thread Raw
In response to Documentation improvement for PQgetResult  (Daniele Varrazzo <daniele.varrazzo@gmail.com>)
Responses Re: Documentation improvement for PQgetResult  (Marko Kreen <markokr@gmail.com>)
List pgsql-docs
Daniele Varrazzo <daniele.varrazzo@gmail.com> writes:
> documentation about the PQgetResult function suggests to "[call]
> repeatedly until it returns a null pointer, indicating that the
> command is done". This has lead psycopg developers to write code with
> the pattern:

>     while (NULL != (res = PQgetResult(conn))) {
>         /* do something with res */
>         PQclear(res);
>     }

> Marko Kreen has pointed out
> (http://lists.initd.org/pipermail/psycopg/2010-July/007149.html) that
> this can lead to an infinite loop if the connection goes bad at the
> rightly wrong time, advising then to check for the connection status
> in the middle of the loop. libpq code seems actually returning
> PQmakeEmptyPGresult(conn, PGRES_FATAL_ERROR) in case of something
> unexpected.

> If this is the case (I've not managed to reproduce it but the libpq
> code seems clear), shouldn't the function documentation warn for this
> risk, advising to check the connection status in the middle of the
> loop and bail out if it's bad?

No.

I'm not convinced we need to do anything about that, since AFAIR no one
has ever reported such a failure from the field (which might well
indicate that Marko's analysis is wrong, anyway).  But if we were to do
something about it, changing the documentation would be the wrong
response, because that coding pattern is all over the place.  It'd be
better to kluge PQgetResult so it only returns a bad-connection error
object once per query, or something like that.

            regards, tom lane

pgsql-docs by date:

Previous
From: Daniele Varrazzo
Date:
Subject: Documentation improvement for PQgetResult
Next
From: Robert Haas
Date:
Subject: Re: Patch for "big features" section of release notes