Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA05236 for ; Wed, 2 Feb 2000 20:36:44 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id UAA24372; Wed, 2 Feb 2000 20:36:22 -0500 (EST) To: blackw@sfu.ca cc: pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] ExecCommandOk() return code always zero? In-reply-to: <3898D1C8.B2FB101B@sfu.ca> References: <3898D1C8.B2FB101B@sfu.ca> Comments: In-reply-to Richard message dated "Wed, 02 Feb 2000 16:54:32 -0800" Date: Wed, 02 Feb 2000 20:36:22 -0500 Message-ID: <24369.949541782@sss.pgh.pa.us> From: Tom Lane Richard writes: > Why would ExecCommandOk() and ExecTuplesOk() be returning these > consistent values? The docs indicate the ExecCommandOk() should be > returning TRUE instead of FALSE, and ExecTuplesOk() should only be > returning TRUE if there are tuples to be retreived. Those docs are certainly wrong about ExecTuplesOk. ExecTuplesOk should return TRUE if your query was valid, regardless of whether any tuples were found. Otherwise, you cannot tell the difference between a bogus query (a syntax error, for example) and a correct query that returned zero tuples. ExecCommandOk is supposed to be used for query types that are incapable of ever returning tuples (INSERT or UPDATE for example). Perhaps it shouldn't return FALSE if you give it a valid SELECT --- that's an interesting philosophical question. The query is "valid" ... but on the other hand, if the application used ExecCommandOk rather than ExecTuplesOk, that implies that it's not expecting to get any tuples back. So *in that context* you could argue that the query is the wrong type of query. Similarly, it's not entirely clear what ExecTuplesOk should do if you hand it an INSERT-type query ... but since that strongly suggests that the application is badly confused, I think raising an error isn't unreasonable. In short, I think we've got a documentation bug here. Can you suggest a revision that would have make it more clear to you? regards, tom lane