Thread: Quirk

Hm, in psql if I set FETCH_COUNT to a nonzero value I suddenly find I'm unable
to use SELECT ... FOR UPDATE.

I suspect this is unnecessary, that the only reason cursors can't hold locks
is because we don't support the kind of read-write operations that clients may
expect to be able to issue against read-write cursors? But if we're using
cursors to work around the libpq interface limitations then perhaps this
restriction shouldn't apply?

postgres=# select * from test for update;
ERROR:  DECLARE CURSOR ... FOR UPDATE/SHARE is not supported
DETAIL:  Cursors must be READ ONLY.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com

Gregory Stark <stark@enterprisedb.com> writes:
> I suspect this is unnecessary, that the only reason cursors can't hold locks
> is because we don't support the kind of read-write operations that clients may
> expect to be able to issue against read-write cursors?

I think the rationale is that the SQL spec defines what DECLARE CURSOR
... FOR UPDATE should mean, and it is not what it would mean in PG if
we simply removed that error check.  If we allow it with PG semantics,
we'll be creating an upward compatibility gotcha for ourselves when
we do finally get around to implementing UPDATE ... WHERE CURRENT OF.
        regards, tom lane