Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> 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