Horton
Menu

Re: SQL:2011 Application Time Update & Delete

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Paul A Jungwirth <pj@illuminatedcomputing.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Chao Li <li.evan.chao@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-20T16:03:30Z
Lists: pgsql-hackers 
Paul A Jungwirth <pj@illuminatedcomputing.com> writes:
> On Mon, Apr 20, 2026 at 7:33 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> But speaking of infinite loops, should this one contain a
>> CHECK_FOR_INTERRUPTS call?  It's hard to conceive of a case where
>> the value would be broken down finely enough for that to be a
>> problem, but ...

> A rangetype could only loop 0-2 times; a multirange 0-1. So I don't
> think we need it. Eventually user-defined types could loop more, but a
> design that inserts many records every time you change something seems
> like a bad idea. Maybe I would add it anyway just out of caution, but
> I suspect it's excessive.

Fair enough.  It's quite likely that we'd hit at least one CFI down
inside the insertion anyway.

			regards, tom lane

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Make ExecForPortionOfLeftovers() obey SRF protocol.

  2. Add isolation tests for UPDATE/DELETE FOR PORTION OF

  3. Add UPDATE/DELETE FOR PORTION OF

  4. Record range constructor functions in pg_range

  5. Add range_minus_multi and multirange_minus_multi functions

  6. doc: Add section for temporal tables

  7. Add assertion check for WAL receiver state during stream-archive transition