public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Eisentraut <[email protected]>
To: Paul A Jungwirth <[email protected]>
Cc: Chao Li <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: SQL:2011 Application Time Update & Delete
Date: Thu, 22 Jan 2026 16:21:54 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+renyWKOj5=rMmQmJcbybu-Vdomxdp=eJ93kp76AgmQKYdfiQ@mail.gmail.com>
References: <[email protected]>
<CA+renyW7ZB_k9AgmSFJU2EegL9r1k1sgWo4-9tGGkgwxNqe6kw@mail.gmail.com>
<CA+renyUodzxAvMnpa_LTvo+Ru1ZKH+Su8KaPvD4iMtguFKzq4g@mail.gmail.com>
<[email protected]>
<CA+renyU-iz_zvM0gGP=dvBPVrz=Jj3qdCjtAh5nLZRhb49xMFw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+renyXchHgpMbYX-cR8fuNnnpf_+FJ6PkHoXoa2AgzRnz4vxQ@mail.gmail.com>
<[email protected]>
<CA+renyXH3AF6JVzZGVcT5mAo=0QncB-MpWJeqb2JG66sgyq09g@mail.gmail.com>
<[email protected]>
<CA+renyUazgR-hB_6RY60n23L0y-n_h9G1AappZmPENO0k5pL1g@mail.gmail.com>
<[email protected]>
<CA+renyVXg5pV84wQnGQuK8-=qoKw3BiBgQzesxM_LkcxxWmYjA@mail.gmail.com>
<[email protected]>
<CA+renyWKOj5=rMmQmJcbybu-Vdomxdp=eJ93kp76AgmQKYdfiQ@mail.gmail.com>
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.
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: SQL:2011 Application Time Update & Delete
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox