From: | Sebastien FLAESCH <sf(at)4js(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Guillaume ERGAND <ger(at)4js(dot)com> |
Subject: | Re: PostgreSQL 8.3, libpq and WHERE CURRENT OF |
Date: | 2007-10-26 13:58:33 |
Message-ID: | 4721F289.7080800@4js.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)4js(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Sebastien FLAESCH | 2007-10-26 14:01:35 | Re: PostgreSQL 8.3, libpq and WHERE CURRENT OF |
Previous Message | Jignesh K. Shah | 2007-10-26 13:36:53 | Re: [HACKERS] 8.3beta1 testing on Solaris |