Feedback-ID: ie0a040ee:Fastmail
Message-ID: <4606deaa-7d65-4f22-8a78-356c3180be9d@eisentraut.org>
Date: Thu, 22 Jan 2026 16:21:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: SQL:2011 Application Time Update & Delete
To: Paul A Jungwirth <pj@illuminatedcomputing.com>
Cc: Chao Li <li.evan.chao@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <ec498c3d-5f2b-48ec-b989-5561c8aa2024@illuminatedcomputing.com>
 <CA+renyW7ZB_k9AgmSFJU2EegL9r1k1sgWo4-9tGGkgwxNqe6kw@mail.gmail.com>
 <CA+renyUodzxAvMnpa_LTvo+Ru1ZKH+Su8KaPvD4iMtguFKzq4g@mail.gmail.com>
 <1ace7bc1-9dd4-42c9-a473-517cef37cce9@eisentraut.org>
 <CA+renyU-iz_zvM0gGP=dvBPVrz=Jj3qdCjtAh5nLZRhb49xMFw@mail.gmail.com>
 <6F8D7105-BD1C-432D-84F3-BC688C0C8EDC@gmail.com>
 <9B820A52-D2F6-465D-B258-6FE8EBA59FAE@gmail.com>
 <CA+renyXchHgpMbYX-cR8fuNnnpf_+FJ6PkHoXoa2AgzRnz4vxQ@mail.gmail.com>
 <53a13f97-340f-4d04-9dcc-77ca3ffb6a6a@eisentraut.org>
 <CA+renyXH3AF6JVzZGVcT5mAo=0QncB-MpWJeqb2JG66sgyq09g@mail.gmail.com>
 <85ac7f0e-d95f-4377-ade0-8941fd328012@eisentraut.org>
 <CA+renyUazgR-hB_6RY60n23L0y-n_h9G1AappZmPENO0k5pL1g@mail.gmail.com>
 <7d63ddfa-c735-4dfe-8c7a-4f1e2a621058@eisentraut.org>
 <CA+renyVXg5pV84wQnGQuK8-=qoKw3BiBgQzesxM_LkcxxWmYjA@mail.gmail.com>
 <e59d218a-ae49-490f-ae6f-86c12f35d3c3@eisentraut.org>
 <CA+renyWKOj5=rMmQmJcbybu-Vdomxdp=eJ93kp76AgmQKYdfiQ@mail.gmail.com>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <CA+renyWKOj5=rMmQmJcbybu-Vdomxdp=eJ93kp76AgmQKYdfiQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/4606deaa-7d65-4f22-8a78-356c3180be9d%40eisentraut.org>
Precedence: bulk

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.