Re: [PATCH] Add UPDATE WHERE OFFSET IN clause

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: Böszörményi Zoltán <zboszor(at)pr(dot)hu>, pgsql-hackers(at)lists(dot)postgresql(dot)org, postgres(at)cybertec(dot)at
Subject: Re: [PATCH] Add UPDATE WHERE OFFSET IN clause
Date: 2022-02-08 01:05:19
Message-ID: 1116946.1644282319@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Chapman Flack <chap(at)anastigmatix(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-02-08 01:12:56 Re: [RFC] building postgres with meson - perl embedding
Previous Message Thomas Munro 2022-02-08 00:51:41 Re: WaitLatchOrSocket seems to not count to 4 right...