Re: PostgreSQL 8.3, libpq and WHERE CURRENT OF
От | Sebastien FLAESCH |
---|---|
Тема | Re: PostgreSQL 8.3, libpq and WHERE CURRENT OF |
Дата | |
Msg-id | 4721F33F.10704@4js.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL 8.3, libpq and WHERE CURRENT OF (Sebastien FLAESCH <sf@4js.com>) |
Ответы |
Re: PostgreSQL 8.3, libpq and WHERE CURRENT OF
|
Список | pgsql-hackers |
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 <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 >> > >
В списке pgsql-hackers по дате отправления: