Re: [HACKERS] PostgreSQL 8.3, libpq and WHERE CURRENT OF

2007-10-28 Thread Sebastien FLAESCH
Just found this in the doc: "WITH HOLD may not be specified when the query includes FOR UPDATE or FOR SHARE" Here is what the Informix doc says about WITH HOLD + FOR UPDATE: "It is possible to declare an update cursor with the WITH HOLD keywords, but the only reason to do so is to break a long

Re: [HACKERS] PostgreSQL 8.3, libpq and WHERE CURRENT OF

2007-10-28 Thread Sebastien FLAESCH
Florian, Do you mean WITH HOLD cursors (+ FOR UPDATE) can also be used to do DELETE/UPDATE WHERE CURRENT OF (i.e. outside transactions) ? From my experience this is an Informix-only feature, but if PostgreSQL supports that it would help a lot to migrate existing applications. I understand it's

Re: [HACKERS] PostgreSQL 8.3, libpq and WHERE CURRENT OF

2007-10-27 Thread Florian G. Pflug
Sebastien FLAESCH wrote: Forget this one, just missing the WITH HOLD option... Must teach myself a bit more before sending further mails. Seb AFAIK you cannot use "WITH HOLD" together with updateable cursors. I might be wrong, though... regards, Florian Pflug ---(end o

Re: [HACKERS] PostgreSQL 8.3, libpq and WHERE CURRENT OF

2007-10-26 Thread Sebastien FLAESCH
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

Re: [HACKERS] PostgreSQL 8.3, libpq and WHERE CURRENT OF

2007-10-26 Thread Sebastien FLAESCH
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 CURS

Re: [HACKERS] PostgreSQL 8.3, libpq and WHERE CURRENT OF

2007-10-26 Thread Sebastien FLAESCH
Tom Lane wrote: Sebastien FLAESCH <[EMAIL PROTECTED]> 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 Bi

Re: [HACKERS] PostgreSQL 8.3, libpq and WHERE CURRENT OF

2007-10-26 Thread Tom Lane
Sebastien FLAESCH <[EMAIL PROTECTED]> 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,

Re: [HACKERS] PostgreSQL 8.3, libpq and WHERE CURRENT OF

2007-10-26 Thread Sebastien FLAESCH
Thanks Heikki for this quick answer. Actually we do the following lipq calls: - PQPrepare(... "SELECT ... FROM ... FOR UPDATE" ... ) - PQexecPrepared(...) - PQntuples(...) / PQgetvalue(...) i.e. we don't use the DECLARE CURSOR instruction, we just prepare/execute the plain SELECT statement (wit

Re: [HACKERS] PostgreSQL 8.3, libpq and WHERE CURRENT OF

2007-10-26 Thread Heikki Linnakangas
Sebastien FLAESCH wrote: > Just looked at the new features of 8.3 and realized that positioned > updates/deletes is now possible with this new release... > > We would use that if we could define the cursor name with a libpq function. I don't understand. When you open a cursor with DECLARE CURSOR,

[HACKERS] PostgreSQL 8.3, libpq and WHERE CURRENT OF

2007-10-26 Thread Sebastien FLAESCH
Hi hackers, Just looked at the new features of 8.3 and realized that positioned updates/deletes is now possible with this new release... We would use that if we could define the cursor name with a libpq function. Something similar to ODBC's SQLSetCursorName() function... For now we must use OI