Re: second DML operation fails with updatable cursor

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: second DML operation fails with updatable cursor
Дата
Msg-id 9909.1193249453@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: second DML operation fails with updatable cursor  (Heikki Linnakangas <heikki@enterprisedb.com>)
Ответы Re: second DML operation fails with updatable cursor  (Heikki Linnakangas <heikki@enterprisedb.com>)
Список pgsql-hackers
Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Our FOR UPDATE cursors aren't exactly INSENSITIVE right now.

Yeah, after re-absorbing the code I realized my earlier comment was out
of date.  I think the true state of affairs is (or should be) that a
cursor declared with FOR UPDATE is sensitive and one without is
insensitive.

>> Another question: if you do DELETE WHERE CURRENT OF, what would you
>> expect to happen to the cursor position?

> According to the spec: before the next row.

AFAICS we cannot really support that without some fairly major revisions
to the way things work --- there's no concept in either the executor or
the cursor-movement stuff of a "hole" within a query's tuple series.
However, the only case that would misbehave is if you try to re-fetch
a row you just deleted, which is a pretty strange thing to do (and
forbidden by spec anyway, I believe) so I think we can leave it as an
unfixed issue for now.  The refetch-after-UPDATE case seems important to
fix, though.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: second DML operation fails with updatable cursor
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: second DML operation fails with updatable cursor