Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 84055B5DC40 for ; Mon, 31 Oct 2011 09:41:41 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 09717-05 for ; Mon, 31 Oct 2011 12:41:34 +0000 (UTC) X-Greylist: delayed 00:31:36.080261 by SQLgrey-1.8.0-rc2 Received: from mx4.framestore.com (mx4.framestore.com [193.203.83.5]) by mail.postgresql.org (Postfix) with ESMTP id 46F9BB5DC5B for ; Mon, 31 Oct 2011 09:41:32 -0300 (ADT) Received: from [172.16.17.9] (helo=zimbra.framestore.com) by mx4.framestore.com with esmtp (Exim 4.72) (envelope-from ) id 1RKqgY-0004cr-OA for pgsql-docs@postgresql.org; Mon, 31 Oct 2011 12:09:53 +0000 Received: from sys880.ldn.framestore.com (sys880.ldn.framestore.com [172.18.58.111]) by zimbra.framestore.com (Postfix) with ESMTPA id A18063F128A for ; Mon, 31 Oct 2011 12:09:45 +0000 (GMT) Date: Mon, 31 Oct 2011 12:09:45 +0000 (GMT) From: Mark Hills To: pgsql-docs@postgresql.org Subject: [PATCH] libpq: Return of NULL from PQexec Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-3.101 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RP_MATCHES_RCVD=-1.201 X-Spam-Level: X-Archive-Number: 201110/74 X-Sequence-Number: 7074 I'm sending the patch below for inclusion. Originally I ran this by pgsql-hackers, just to confirm the docs (and not the code) were in need of the fix, which seems to be the case: http://archives.postgresql.org/pgsql-hackers/2011-09/msg00614.php Thanks -- Mark ---------- Forwarded message ---------- Date: Mon, 12 Sep 2011 16:40:28 +0100 (BST) From: Mark Hills To: pgsql-hackers@postgresql.org Subject: libpq: Return of NULL from PQexec The libpq documentation for PQexec states: "If a null pointer is returned, it should be treated like a PGRES_FATAL_ERROR result" But this contradicts the example programs; eg. from Example Program 1: /* Start a transaction block */ res = PQexec(conn, "BEGIN"); if (PQresultStatus(res) != PGRES_COMMAND_OK) { fprintf(stderr, "BEGIN command failed: %s", PQerrorMessage(conn)); PQclear(res); exit_nicely(conn); } which does not check if (res != NULL). The example is not buggy -- PQresultStatus, PQerrorMessage and, importantly, PQclear deal with the NULL value; eg. src/libpq/fq-exec.c: ExecStatusType PQresultStatus(const PGresult *res) { if (!res) return PGRES_FATAL_ERROR; return res->resultStatus; } So I took the example to be correct, and attempted to fix the documentation in the patch below. I hope this is useful. In a straw-poll of code I could find using libpq, I found most follows the example and is reliant on libpq for its NULL check. The same also applies to PQconnect functions -- and PQstatus, PQfinish, which I also tried to clarify in the documentation. Thanks -- Mark diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 163a893..57be7e1 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -62,7 +62,7 @@ return a non-null object pointer, unless perhaps there is too little memory even to allocate the PGconn object. The PQstatus function should be called to check - whether a connection was successfully made before queries are sent + the return value for a successful connection before queries are sent via the connection object. @@ -1748,8 +1748,10 @@ PGresult *PQexec(PGconn *conn, const char *command); Returns a PGresult pointer or possibly a null pointer. A non-null pointer will generally be returned except in out-of-memory conditions or serious errors such as inability to send - the command to the server. If a null pointer is returned, it should - be treated like a PGRES_FATAL_ERROR result. Use + the command to the server. The PQresultStatus function + should be called to check the return value for any errors (including + the value of a null pointer, in which case it will return + PGRES_FATAL_ERROR). Use PQerrorMessage to get more information about such errors.