Gaetano Mendola <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Really? AFAICS, CommandIsReadOnly() will reject SELECT FOR UPDATE too.
> kalman$# FOR my_port_set IN
> kalman$# SELECT a
> kalman$# FROM test
> kalman$# FOR UPDATE
> kalman$# LOOP
Hm, that's a bug --- SPI_cursor_open is failing to check for a read-only
query.
> BTW why forbid the lock in a non volatile function or (if you fix this)
> the SELECT FOR UPDATE ?
Well, as for the lock, a non-volatile function isn't supposed to have
any side-effects, and taking a lock is certainly a side-effect no?
Now I suppose it'll be taking AccessShareLock anyway if it reads any
tables, so maybe we could negotiate about what sort of locks could be
allowed; but I'd certainly argue that allowing it to take any kind of
exclusive lock would be a Bad Idea.
As for SELECT FOR UPDATE, there's a very good reason for disallowing
that even without considering what locks it takes. In a READ COMMITTED
transaction, SELECT FOR UPDATE can return row states that aren't visible
according to the nominal transaction snapshot, and so it violates the
promise of stable results.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
