Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 063A99FCA26 for ; Fri, 26 Oct 2007 11:02:48 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 39627-02 for ; Fri, 26 Oct 2007 11:02:34 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mail2007.strasbourg.4js.com (mail2007.strasbourg.4js.com [84.14.60.197]) by postgresql.org (Postfix) with ESMTP id 83EBA9FC94E for ; Fri, 26 Oct 2007 11:02:41 -0300 (ADT) Received: from [10.0.0.196] (fox.strasbourg.4js.com [10.0.0.196]) (authenticated bits=0) by mail2007.strasbourg.4js.com (8.13.8/8.13.8/Debian-3) with ESMTP id l9QE2cb2006891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Oct 2007 16:02:38 +0200 Message-ID: <4721F33F.10704@4js.com> Date: Fri, 26 Oct 2007 16:01:35 +0200 From: Sebastien FLAESCH Organization: Four J's Development Tools User-Agent: Thunderbird 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: Sebastien FLAESCH CC: Tom Lane , Heikki Linnakangas , pgsql-hackers@postgresql.org, Guillaume ERGAND Subject: Re: PostgreSQL 8.3, libpq and WHERE CURRENT OF References: <4721BAFE.3080601@4js.com> <4721BF34.80901@enterprisedb.com> <4721DECF.80401@4js.com> <10801.1193404182@sss.pgh.pa.us> <4721F289.7080800@4js.com> In-Reply-To: <4721F289.7080800@4js.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4599/Fri Oct 26 13:27:38 2007 on mail2007.strasbourg.4js.com X-Virus-Status: Clean X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200710/1336 X-Sequence-Number: 109704 Forget this one, just missing the WITH HOLD option... Must teach myself a bit more before sending further mails. Seb Sebastien FLAESCH wrote: > Ok... > > Tested with 8.2.3: > > Actually you can't DECLARE a cursor outside a transaction: > > test1=> declare c1 cursor for select * from dbit2; > ERROR: DECLARE CURSOR may only be used in transaction blocks > > That's the main reason why we don't use DECLARE CURSOR... > > I understand we could use DECLARE CURSOR when a FOR UPDATE is > detected, to allow UPDATE/DELETE WHERE CURRENT OF - these only > make sense inside a transaction... > > But for normal cursors, we need to support multiple active result > sets that can last outside a transaction block. > > Basically, we need all what you can do with ODBC cursors. > > Anyway, thanks for your help. > > Seb > > Tom Lane wrote: >> Sebastien FLAESCH writes: >>> Does a simple PQPrepare() with a SELECT statement not create a cursor on >>> the server side? >> >> No. A prepared statement is just a query plan, not a query-in-progress. >> >> The Bind/Execute messages sent by PQexecPrepared create something akin >> to a cursor, but libpq doesn't expose any API for fetching one row at a >> time in that context, so there's no way to use the "current row" anyway. >> >> regards, tom lane >> > >