Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> How could there be a concurrent update of the _same_ row, when
>> I do "select * from bar *for update*".
>
> AFAICT the spec doesn't require one to have written FOR UPDATE
> in order to use WHERE CURRENT OF. (In effect, they expect FOR UPDATE
> to be the default, which is certainly not a change we're going to
> want to make to DECLARE CURSOR.) If we did make that restriction
> then we could probably skip the EvalPlanQual mess.
But if the expect "for update" to be default, then essentially they
do require that one to use a cursor with "for update" semantics when
using "where current of" - or do they allow "where current of" even
for "not for update" cursors?
If one would restrict in implementation of "where current of" to
"for update", "without hold" cursors, the only non-trivial problem that
I can see is how to support more than one update of the same row.
Because as far as I can see, if you'd do
begin;
declare foo cursor select * from bar for update;
fetch foo into v_foo ;
update bar set ... where ctid = v_foo.ctid ;
update bar set ... where ctid = v_foo.ctid ;
commit;
the second update would silently be ignored. But since only
updates happing in the same transaction would somehow need to be
tracked, this should be much easier to do than supporting
the non-for-update case.
greetings, Florian Pflug