Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UgD9U-0006g5-QV for pgsql-sql@arkaria.postgresql.org; Sat, 25 May 2013 12:00:49 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UgD9U-0005aI-BW for pgsql-sql@arkaria.postgresql.org; Sat, 25 May 2013 12:00:48 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UgD9T-0005aC-Cl for pgsql-sql@postgresql.org; Sat, 25 May 2013 12:00:47 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UgD9Q-00065u-9R for pgsql-sql@postgresql.org; Sat, 25 May 2013 12:00:46 +0000 Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4B60E20BD7; Sat, 25 May 2013 08:00:41 -0400 (EDT) Received: from web5.nyi.mail.srv.osa ([10.202.2.215]) by compute5.internal (MEProxy); Sat, 25 May 2013 08:00:42 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=ijxrHfUrqPVvhsdx2eW/QSf8nNw=; b=Af6D8sTbXbuRHRDyO37l+VjX1PeP 1FnrYbkNoJ4PC1tV6BzsvJ3s3xfTTHVm9TeSWJIUgItirIjRu4deJGWKgOwGON4h jfZt/GwmAAqdNmm4O63cSbaxoiGuGCTpmJ5OSIz3w5OaOzG4PWWMI8DQ+SYi9/YQ k/7TcggDZ3xKxi0= Received: by web5.nyi.mail.srv.osa (Postfix, from userid 99) id 69A90DD62A9; Sat, 25 May 2013 08:00:41 -0400 (EDT) Message-Id: <1369483241.9028.140661235555577.5F2DB852@webmail.messagingengine.com> X-Sasl-Enc: 7DnOwnnbrocnEr3pkKmoF1vVVrYfL1oG6zzc9HPt/tFW 1369483241 From: Wolfe Whalen To: =?iso-8859-1?Q?Brice=20Andr=E9?= , pgsql-sql@postgresql.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_136948324190280"; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-bbf0154f Subject: Re: DELETE...RETURNING problem with libpq Date: Sat, 25 May 2013 05:00:41 -0700 X-Pg-Spam-Score: 0.1 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org This is a multi-part message in MIME format. --_----------=_136948324190280 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi Brice, I believe that you'll need PQcmdTuples - "Returns the number of rows affected by the SQL command." Watch out, it returns char* instead of int. I believe it's supposed to be used for the UPDATE ... RETURNING as well, but I'd double check on that. It's under "30.3.3. Retrieving Result Information for Other Commands" in the 8.4 docs ("These functions are used to extract information from PGresult objects that are not SELECT results."): [1]http://www.postgresql.org/docs/8.4/static/libpq-exec.html Let us know if that helps or if we should dig into it a little deeper. Best regards, Wolfe -- Wolfe Whalen wolfe@quios.net On Sat, May 25, 2013, at 04:07 AM, Brice Andr=E9 wrote: Dear all, I am trying to translate a code written in php to C++. So, I am now using lipq in order to access my postgresql database from C++. As performance is an important feature, I am using prepared statements. I have a SQL statement that performs a 'DELETE ... RETURNING ... ' stuff and I execute it from a prepared statement (using PQprepare and PQexecPrepared). Now, when I execute this command, it properly deletes requested row, but when I use command PQntuples, it returns 0, as if no data was returned. When I execute the same sql command from PgAdmin or from my old php script (that did not use prepared statements), everything works fine. Note that, in another part of my script, I use the same technique to perform an 'UPDATE ... RETURNING' and it works properly... Does anyone has an idea of what may fail and how I can solve this problem ? Regards, Brice PS : my postgresql server version is 8.4 and it is running on a Debian server, if it may help. References 1. http://www.postgresql.org/docs/8.4/static/libpq-exec.html --_----------=_136948324190280 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
Hi Brice,
 
I believe that you'll need PQcmdTuples - "Returns the numbe= r of rows affected by the SQL command."
 
Watch out, it returns char* instead of int.  I believe it's suppo= sed to be used for the UPDATE ... RETURNING as well, but I'd double check o= n that.
 
It's under "30.3.3. Retrieving Result Information for Other Commands" = in the 8.4 docs ("These functions are used to extract information = from PGresult=  objects that are not SELEC= T results."):
 
Let us know if that helps or if we should dig into it a little deeper.=
 
Best regards,
 
Wolfe
 
--
Wolfe Whalen
wolfe@quios.net
 
 
 
On Sat, May 25, 2013, at 04:07 AM, Brice Andr=E9 wrote:
Dear all,
 
I am trying to translate a code written in php to C++. So, I am now us= ing lipq in order to access my postgresql database from C++.
 
As performance is an important feature, I am using prepared statements= .
 
I have a SQL statement that performs a 'DELETE ... RETURNING ... ' stu= ff and I execute it from a prepared statement (using PQprepare and PQexecPr= epared). Now, when I execute this command, it properly deletes requested ro= w, but when I use command PQntuples, it returns 0, as if no data was return= ed.
 
When I execute the same sql command from PgAdmin or from my old php sc= ript (that did not use prepared statements), everything works fine.
 
Note that, in another part of my script, I use the same technique to p= erform an 'UPDATE ... RETURNING' and it works properly...
 
Does anyone has an idea of what may fail and how I can solve this prob= lem ?
 
Regards,
Brice
 
PS : my postgresql server version is 8.4 and it is running on a Debian= server, if it may help.
--_----------=_136948324190280--