Re: [PATCH] Add UPDATE WHERE OFFSET IN clause

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] Add UPDATE WHERE OFFSET IN clause
Дата
Msg-id 1116946.1644282319@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] Add UPDATE WHERE OFFSET IN clause  (Chapman Flack <chap@anastigmatix.net>)
Ответы Re: [PATCH] Add UPDATE WHERE OFFSET IN clause  (Böszörményi Zoltán <zboszor@pr.hu>)
Список pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> On 02/07/22 00:59, Böszörményi Zoltán wrote:
>> UPDATE ... WHERE OFFSET n IN cursor;

> If added to UPDATE, should this be added to DELETE also?

FWIW, I think this is a really horrid hack.  For one thing, it's not
robust against not-strictly-linear FETCH/MOVE of the cursor.  It looks
to me like "OFFSET n" really means "the row that we read N reads ago",
not "the row N before the current cursor position".  I see that the
documentation does explain it that way, but it fails to account for
optimizations such as whether we implement moves by reading backwards
or rewind-and-read-forwards.  I don't think we want to expose that
sort of implementation detail.

I'm also pretty displeased with causing unbounded memory consumption for
every use of nodeLockRows, whether it has anything to do with a cursor or
not (never mind whether the cursor will ever be used for WHERE OFFSET IN).
Yeah, it's only a few bytes per row, but that will add up in queries that
process lots of rows.

            regards, tom lane



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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: WaitLatchOrSocket seems to not count to 4 right...
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [RFC] building postgres with meson - perl embedding