Message-ID: <4721EA65.2050806@4js.com>
Date: Fri, 26 Oct 2007 15:23:49 +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

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.

Yes of course, I meant PQprepare() + PQexecPrepared() ...

> 
> 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.

OK... that makes total sense (sorry I jump from one database to another
and sometimes I forget implementation details of a specific driver).

Sounds like I need to rework my driver to enable row by row fetching
with the DECLARE CURSOR + FETCH commands... right?

As I wrote: I knew these commands before, but for some reason I did not
use that solution because I faced problems.

I started with PostgreSQL 7.1 so maybe there was some limitation that
does no more exist in 8.x ...

Maybe it was because there is not real OPEN command, so you can't
distinguish the preparation phase from the execution phase with the
DECLARE CURSOR instruction...

Or maybe because cursors could only exist inside a transaction block?

Just found this in the 7.1 doc:
http://www.postgresql.org/docs/7.1/static/sql-declare.html
"
ERROR: DECLARE CURSOR may only be used in begin/end transaction blocks
This error occurs if the cursor is not declared within a transaction block.
"

Anyway...

Thanks a lot guys for these quick answers.
That changes from Oracle or SQL Server support.
Seb