Re: SQL:2011 Application Time Update & Delete

Peter Eisentraut <peter@eisentraut.org>

From: Peter Eisentraut <peter@eisentraut.org>
To: Paul A Jungwirth <pj@illuminatedcomputing.com>
Cc: Chao Li <li.evan.chao@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-01-22T15:21:54Z
Lists: pgsql-hackers
I have committed the pg_range patch.

On 19.01.26 19:33, Paul A Jungwirth wrote:
> Do we want a regress test in rangetypes.sql to confirm that these are
> set correctly (especially for user-defined types)? I checked manually
> after `make installcheck`, and they look fine, but should it be in our
> test suite?

I think the existing tests do that, since type_sanity runs after the 
rangetypes test.

> Here is another thought I had: As we've talked about in the
> application-time threads, I would like temporal features to be
> extensible enough to support user-defined types. We almost achieve
> that, but we need something like a "type support function". For primary
> key and unique constraints, we need a way to reject invalid values like
> empty ranges. For foreign keys we need an intersect operator (which is
> not currently in pg_amop, since it is neither for search nor ordering,
> and isn't involved in indexes anyway). And for UPDATE/DELETE FOR
> PORTION OF we need a foo_minus_multi to compute the "temporal
> leftovers".
> 
> We could also ask for a constructor function, to build the targeted
> portion from the FROM/TO bounds. This is not strictly necessary, since
> we also have the FOR PORTION OF valid_at (...) syntax (which is used by
> multiranges). But it's something that would be nice to offer. In that
> case range types would not need these extra columns in pg_range.
> 
> But recording the constructor oids in pg_range still has inherent
> value, and doing it now doesn't *prevent* us from later adding a
> facility to get a constructor function for FOR PORTION OF bounds. So I
> don't think there is any downside to recording them here.

Right, that sounds like a future project.




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