Message-ID: <4721F289.7080800@4js.com>
Date: Fri, 26 Oct 2007 15:58:33 +0200
From: Sebastien FLAESCH <sf@4js.com>
Organization: Four J's Development Tools
User-Agent: Thunderbird 1.5.0.9 (X11/20061220)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Heikki Linnakangas <heikki@enterprisedb.com>,
 pgsql-hackers@postgresql.org,
	Guillaume ERGAND <ger@4js.com>
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>
In-Reply-To: <10801.1193404182@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 <sf@4js.com> 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
>