[DOCS] Documentation improvement for PQgetResult

2010-08-06 Thread Daniele Varrazzo 
Hello,

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? Would it be better to perform a check
on the connection or on the result?

Thank you, cheers.

-- Daniele

-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] Documentation improvement for PQgetResult

2010-08-06 Thread Tom Lane 
Daniele Varrazzo  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

-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] Patch for "big features" section of release notes

2010-08-06 Thread Robert Haas 
On Tue, Aug 3, 2010 at 8:40 PM, Josh Berkus  wrote:
> Attached is a patch re-arranging some of the features in the first part
> of the release notes, as well as adding a few.  The additions are based
> on (a) votes on what's a big feature for 9.0, and (b) a desire to match
> the features listed elsewhere, such as the press kit.

This patch reverts a bunch of the changes in Erik Rijkers' previous
doc patch.  Since you didn't mention anything about that, I'm guessing
it was unintentional.  Using git can help avoid these kinds of
mistakes... rebase is your friend.  If it was intentional, let's
discuss.  Anyhow, I've somewhat painstakingly extracted what I believe
to be the intentional changes and am committing those now.  Please
check.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

Re: [DOCS] Please provide stable target anchors

2010-08-06 Thread Robert Haas 
On Wed, Aug 4, 2010 at 3:03 PM, Daniele Varrazzo
 wrote:
> I have prepared patches to add ids style 'libpq-pqconnectdb' to
> varlistentry relative to libpq functions. This results in stable
> anchors in html output. The ids have been generated using the script
> available in .
>
> lobj.sgml doesn't use libpq so I've added ids to the sect2 tags, which
> are local enough. I've added them manually as are not so many.
>
> Patches are available from the git clone at
> . I've prepared patches for 8.4
> and 9.0 (branches "fixanchor-8-4" and "fixanchor-9-0").

Could you post a diff?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs

[DOCS] pgbench acronym tps

2010-08-06 Thread Erik Rijkers 
I noticed that pgbench.sgml (or the manual elsewhere)
does not explicitly mention what TPS stands for;
I thought it might be useful to add.

(reason I checked: someone on #postgresql took tps
to mean 'tuples per second')


Erik Rijkers


pgbench.sgml.diff
Description: Binary data

-- 
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs