Re: PostgreSQL 8.3, libpq and WHERE CURRENT OF
От | Sebastien FLAESCH |
---|---|
Тема | Re: PostgreSQL 8.3, libpq and WHERE CURRENT OF |
Дата | |
Msg-id | 4721F289.7080800@4js.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL 8.3, libpq and WHERE CURRENT OF (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PostgreSQL 8.3, libpq and WHERE CURRENT OF
|
Список | 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@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 по дате отправления: