To: Daniele Varrazzo <daniele.varrazzo@gmail.com>
cc: pgsql-docs@postgresql.org, Marko Kreen <markokr@gmail.com>
Subject: Re: Documentation improvement for PQgetResult 
In-reply-to: <AANLkTikP5a0yHUNYJC+p+KadnyNH+Wmbt=QkZ=rZYE9O@mail.gmail.com> 
References: <AANLkTikP5a0yHUNYJC+p+KadnyNH+Wmbt=QkZ=rZYE9O@mail.gmail.com>
Comments: In-reply-to Daniele Varrazzo <daniele.varrazzo@gmail.com>
	message dated "Fri, 06 Aug 2010 14:53:38 +0100"
Date: Fri, 06 Aug 2010 10:20:18 -0400
Message-ID: <18521.1281104418@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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