Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TRtnT-0006Az-Oz for pgsql-docs@postgresql.org; Fri, 26 Oct 2012 23:58:39 +0000 Received: from mail-oa0-f46.google.com ([209.85.219.46]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TRtnP-0006OD-IC for pgsql-docs@postgresql.org; Fri, 26 Oct 2012 23:58:38 +0000 Received: by mail-oa0-f46.google.com with SMTP id h16so3178724oag.19 for ; Fri, 26 Oct 2012 16:58:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=EADr011Sgipb0tuvSib0CpVyBZtIJm8X5ACkQ08wo60=; b=B2Kt9Qi9LSpwyHFowe8b4rCnnbX4NSPtXNu1MvPlyzyQDBO+/BRAwDWEzgiXFf6Gq6 WM725dp/IzWdMDulGvWvFOZK+uGDjUEJTk7yuomGDTTqIR3RhFVjj5EecBdw4Jjki/lS Z2+nvLcnIhOef2IuxG5wPqwraQ3GdKyGBx1H7QSQSkCVcEyjn6ICwRC5CdyUQWMfnqOq +VXJ2iDTlCa8z0yUKuko5UoEOc4dpzKnFoKh96Rj54aW2y3zdTdfED4oxe7JSb3yb+F+ ywQdJaFEdY9y5q7QqtOvtxGijCIwQUfXEhDXyfv4aealmL13bkEToH4xbavV+KYDJCWp lwjg== Received: by 10.60.1.164 with SMTP id 4mr3466858oen.96.1351295913965; Fri, 26 Oct 2012 16:58:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.101.201 with HTTP; Fri, 26 Oct 2012 16:58:13 -0700 (PDT) From: Josh Kupershmidt Date: Fri, 26 Oct 2012 16:58:13 -0700 Message-ID: Subject: example for PGRES_COMMAND_OK To: pgsql-docs Content-Type: multipart/mixed; boundary=e89a8fb1ffe2f03a2f04ccff18b9 X-Pg-Spam-Score: -2.7 (--) X-Archive-Number: 201210/8 X-Sequence-Number: 7488 --e89a8fb1ffe2f03a2f04ccff18b9 Content-Type: text/plain; charset=ISO-8859-1 Hi all, This libpq page: http://www.postgresql.org/docs/current/static/libpq-exec.html#LIBPQ-PQRESULTSTATUS has claimed since at least the 7.x days: | PGRES_COMMAND_OK is for commands that can never return rows (INSERT, UPDATE, etc.) However, as of 8.2 we support the popular INSERT ... RETURNING and UPDATE ... RETURNING, both of which will naturally give a successful PQresultStatus() of PGRES_TUPLES_OK. So I think this explanation deserves an amendment. We could just change the example commands to e.g. TRUNCATE for simplicity, but I do like that the current example commands are INSERT and UPDATE, since it reinforces the notion that a plain INSERT or UPDATE affecting no rows would still return PGRES_COMMAND_OK. Suggested change attached. Josh --e89a8fb1ffe2f03a2f04ccff18b9 Content-Type: application/octet-stream; name="libpq.PGRES_COMMAND_OK.diff" Content-Disposition: attachment; filename="libpq.PGRES_COMMAND_OK.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h8rykd0k0 ZGlmZiAtLWdpdCBhL2RvYy9zcmMvc2dtbC9saWJwcS5zZ21sIGIvZG9jL3NyYy9zZ21sL2xpYnBx LnNnbWwKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMjU1YzVjMS4uYTZhMTc5ZQoqKiogYS9k b2Mvc3JjL3NnbWwvbGlicHEuc2dtbAotLS0gYi9kb2Mvc3JjL3NnbWwvbGlicHEuc2dtbAoqKioq KioqKioqKioqKiogRXhlY1N0YXR1c1R5cGUgUFFyZXN1bHRTdGF0dXMoY29uc3QgUEdyZQoqKiog MjQ0NSwyNDUxICoqKioKICAgICAgICAgIGNvbW1hbmQgdGhhdCBoYXBwZW5zIHRvIHJldHJpZXZl IHplcm8gcm93cyBzdGlsbCBzaG93cwogICAgICAgICAgPGxpdGVyYWw+UEdSRVNfVFVQTEVTX09L PC9saXRlcmFsPi4KICAgICAgICAgIDxsaXRlcmFsPlBHUkVTX0NPTU1BTkRfT0s8L2xpdGVyYWw+ IGlzIGZvciBjb21tYW5kcyB0aGF0IGNhbiBuZXZlcgohICAgICAgICAgcmV0dXJuIHJvd3MgKDxj b21tYW5kPklOU0VSVDwvY29tbWFuZD4sIDxjb21tYW5kPlVQREFURTwvY29tbWFuZD4sCiAgICAg ICAgICBldGMuKS4gQSByZXNwb25zZSBvZiA8bGl0ZXJhbD5QR1JFU19FTVBUWV9RVUVSWTwvbGl0 ZXJhbD4gbWlnaHQKICAgICAgICAgIGluZGljYXRlIGEgYnVnIGluIHRoZSBjbGllbnQgc29mdHdh cmUuCiAgICAgICAgIDwvcGFyYT4KLS0tIDI0NDUsMjQ1MiAtLS0tCiAgICAgICAgICBjb21tYW5k IHRoYXQgaGFwcGVucyB0byByZXRyaWV2ZSB6ZXJvIHJvd3Mgc3RpbGwgc2hvd3MKICAgICAgICAg IDxsaXRlcmFsPlBHUkVTX1RVUExFU19PSzwvbGl0ZXJhbD4uCiAgICAgICAgICA8bGl0ZXJhbD5Q R1JFU19DT01NQU5EX09LPC9saXRlcmFsPiBpcyBmb3IgY29tbWFuZHMgdGhhdCBjYW4gbmV2ZXIK ISAgICAgICAgIHJldHVybiByb3dzICg8Y29tbWFuZD5JTlNFUlQ8L2NvbW1hbmQ+IG9yIDxjb21t YW5kPlVQREFURTwvY29tbWFuZD4KISAgICAgICAgIHdpdGhvdXQgYSA8bGl0ZXJhbD5SRVRVUk5J Tkc8L2xpdGVyYWw+IGNsYXVzZSwKICAgICAgICAgIGV0Yy4pLiBBIHJlc3BvbnNlIG9mIDxsaXRl cmFsPlBHUkVTX0VNUFRZX1FVRVJZPC9saXRlcmFsPiBtaWdodAogICAgICAgICAgaW5kaWNhdGUg YSBidWcgaW4gdGhlIGNsaWVudCBzb2Z0d2FyZS4KICAgICAgICAgPC9wYXJhPgo= --e89a8fb1ffe2f03a2f04ccff18b9--