Gaetano Mendola 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

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 4 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMar 16, '07 at 8:54a
activeMar 17, '07 at 2:17a
posts4
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Gaetano Mendola: 2 posts Tom Lane: 2 posts

People

Translate

site design / logo © 2022 Grokbase