Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id DACDCB5DC1A for ; Tue, 20 Sep 2011 20:54:45 -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 12392-09 for ; Tue, 20 Sep 2011 23:54:38 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from polaris.pinpointresearch.com (cerberus.pinpointresearch.com [66.7.238.130]) by mail.postgresql.org (Postfix) with ESMTP id 7235FB5DC0A for ; Tue, 20 Sep 2011 20:54:38 -0300 (ADT) Received: from betelgeuse.pinpointresearch.com (betelgeuse.pinpointresearch.com [192.168.1.179]) by polaris.pinpointresearch.com (Postfix) with ESMTP id D0214E00EC84; Tue, 20 Sep 2011 16:54:37 -0700 (PDT) Message-ID: <4E7927BD.50404@pinpointresearch.com> Date: Tue, 20 Sep 2011 16:54:37 -0700 From: Steve Crawford User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 MIME-Version: 1.0 To: Marc Fromm CC: "pgsql-admin@postgresql.org Admin" Subject: Re: currval() References: <93361C67E4EE844A80935863A4FF4B6C051150A2@Exch2010MB-2.univ.dir.wwu.edu> <4E791940.1040903@pinpointresearch.com> <93361C67E4EE844A80935863A4FF4B6C05115121@Exch2010MB-2.univ.dir.wwu.edu> In-Reply-To: <93361C67E4EE844A80935863A4FF4B6C05115121@Exch2010MB-2.univ.dir.wwu.edu> Content-Type: multipart/alternative; boundary="------------080908030309060205040802" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.403 tagged_above=-10 required=5 tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.504 X-Spam-Level: X-Archive-Number: 201109/143 X-Sequence-Number: 38380 This is a multi-part message in MIME format. --------------080908030309060205040802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/20/2011 04:06 PM, Marc Fromm wrote: > > My postgres version is 8.1. Last I heard RETURNING id started in 8.2. > I'd advise upgrading. 8.1 is no-longer supported (end-of-life was last November) and 8.2 has an end-of-life date in just a couple months. You'll get security and bug fixes, performance benefits and, of course, those cool new features you need. :) (No security fixes is often the issue that gets management attention if necessary.) > Is not my semicolon before the select statement make it two sequential > staements? > > I don't get an sql error when it is executed. > Well, it is technically legal (and why SQL injection can work). Looks like you are using PHP and PHP says that if you bundle statements together they will be executed as a transaction. Perhaps it's personal preference, but combining statements like that is difficult to read and I suspect will make bugs hard to find. And although I can't find it documented, it appears that the return value is only from the final statement. I shy away from undocumented behaviour and I'd rather be able to check the result of each statement. > I did learn from another reply that my select statement was wrong. I > needed to SELECT currval('jobs_id_seq') not the field name, which I > was doing. > Yes, this is probably the real root of your problem. I did not notice that since I didn't have the table definition in front of me. Cheers, Steve --------------080908030309060205040802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/20/2011 04:06 PM, Marc Fromm wrote:

My postgres version is 8.1. Last I heard RETURNING id started in 8.2.

I'd advise upgrading. 8.1 is no-longer supported (end-of-life was last November) and 8.2 has an end-of-life date in just a couple months. You'll get security and bug fixes, performance benefits and, of course, those cool new features you need. :)

(No security fixes is often the issue that gets management attention if necessary.)

Is not my semicolon before the select statement make it two sequential staements?

I don’t get an sql error when it is executed.

Well, it is technically legal (and why SQL injection can work). Looks like you are using PHP and PHP says that if you bundle statements together they will be executed as a transaction.

Perhaps it's personal preference, but combining statements like that is difficult to read and I suspect will make bugs hard to find. And although I can't find it documented, it appears that the return value is only from the final statement. I shy away from undocumented behaviour and I'd rather be able to check the result of each statement.

I did learn from another reply that my select statement was wrong. I needed to SELECT currval('jobs_id_seq') not the field name, which I was doing.

Yes, this is probably the real root of your problem. I did not notice that since I didn't have the table definition in front of me.

Cheers,
Steve

--------------080908030309060205040802--