Re: UPDATE/DELETE XXX WHERE CURRENT OF cursor_name
От | Florian G. Pflug |
---|---|
Тема | Re: UPDATE/DELETE XXX WHERE CURRENT OF cursor_name |
Дата | |
Msg-id | 44C4F036.1070605@phlo.org обсуждение исходный текст |
Ответ на | Re: UPDATE/DELETE XXX WHERE CURRENT OF cursor_name (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: