Re: updateable cursors & visibility
От | Peter Eisentraut |
---|---|
Тема | Re: updateable cursors & visibility |
Дата | |
Msg-id | Pine.LNX.4.44.0303271011280.2228-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: updateable cursors & visibility (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: updateable cursors & visibility
|
Список | pgsql-hackers |
Bruce Momjian writes: > One idea is to require FOR UPDATE on the cursor --- while that prevents > other transactions from changing the cursor, it doesn't deal with the > current transaction modifying the table outside the cursor. That would only keep existing rows from being deleted but not new rows from being added. > One idea is > to have UPDATE/DELETE WHERE CURRENT OF behave like UPDATE/DELETE do now > when they find a row that is locked by another transaction --- they wait > to see if the transaction commits or aborts, then if committed they > follow the tid to the newly updated row, check the WHERE clause to see > if it still is satisfied, then perform the update. (Is this correct?) Surely it would have to do something like that, but that's a matter of the transaction isolation, not the sensitivity. It doesn't do anything to address the potential problems I mentioned. -- Peter Eisentraut peter_e@gmx.net
В списке pgsql-hackers по дате отправления: