Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Couldn't this be emulated by doing
begin;
declare foo cursor for select * from bar for update;
fetch foo into v_foo ;
update bar set abc='def' where ctid = v_foo.ctid;
That wouldn't follow the expected semantics if there's a concurrent
update, because the updated row would always fail the WHERE clause,
and thus the update would just silently not happen. (I'm thinking
about READ COMMITTED mode of course --- in SERIALIZABLE you'd just get
the expected error.) You'd have to find some way to pump the row's most
up-to-date version through the cursor's query plan, a la EvalPlanQual,
to see if it still met the cursor's WHERE condition.
How could there be a concurrent update of the _same_ row, when
I do "select * from bar *for update*". Or are you talking about
concurrent updates to the same page that could somehow alter
the ctid of _another_ tuple?
greetings, Florian Pflug
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
