Re: SQL:2011 Application Time Update & Delete

On Sun, Jun 1, 2025 at 10:24 PM Paul Jungwirth
<pj(at)illuminatedcomputing(dot)com> wrote:
> Please stay tuned for some actual patches!

Hi Hackers,

Here are updated patches for UPDATE/DELETE FOR PORTION OF and related
functionality. I left out the usual PERIODs patch because I'm still
updating it to work with the latest master. (Every time cataloged NOT
NULL constraints change, it has rebase conflicts. :-)

I wrote a long wiki page to summarize progress on this patch and other
application-time patches:
https://wiki.postgresql.org/wiki/ApplicationTimeProgress The main goal
is to record design decisions and their rationale, so we don't have to
revisit those or scour the archives for them. It also has a "Progress"
section to show what is done and what remains. Hopefully that will
help people jump in and understand what's happening. I'll link to it
from the commitfest entry and keep it up-to-date.

That page does *not* introduce general concepts for application time,
although I think that is needed too. But we already have another page
for that (sort of). I added an application-time section to this old
wiki page: https://wiki.postgresql.org/wiki/SQL2011Temporal Before my
edits, that page only covered System Time, along with a proposal from
2012-2015 for implementing it with triggers. I kept all that but moved
it into a "System Time" section.

Notable things about the current patch set:

- I added a new chapter to the docs to introduce temporal concepts.
This gives us a more convenient place to explain concepts and link to
them. I made separate patches for primary keys and foreign keys, in
case we want to include those in v18. I made a separate patch for
PERIODs also, which we could include now if we wanted: it explains
that the current functionality uses ranges & multiranges, but we plan
to support periods in the future. The last doc patch is for
UPDATE/DELETE FOR PORTION OF. It introduces the term "temporal
leftovers", which is very helpful when explaining the implicit INSERTs
from an UPDATE/DELETE FOR PORTION OF. Those patches add some more
glossary entries as well. I also tried to improve how the docs discuss
multiranges, since sometimes they only covered rangetypes.

- Instead of an opclass support proc named without_portion, I just
added Set-Returning Functions named range_minus_multi and
multirange_minus_multi, and those are hardcoded for the matching type.
They serve the same purpose: to find the temporal leftovers. If we
wanted to support user-defined types in the future, they could bring
their own SRFs. These functions would also be used for foreign keys
with RESTRICT (depending on how we interpret the standard).

- I abandoned the SPI implementation and went back to just preparing a
TupleTableSlot and calling ExecInsert with it. This was my original
implementation up 'til last year, but I switched to SPI to get correct
trigger behavior. But making triggers do the right thing turned out to
be not so hard after all. See my last email on this thread for lots of
details about how triggers should behave.

- I added tests for protocol tags with FOR PORTION OF. The count from
an update/delete *includes the INSERTs*. This seems consistent with
INSERT ON CONFLICT, which also gives you a count that combines both
inserts and updates. They both have the same mental model (for me at
least) of returning the number of tuples touched. Since FOR PORTION OF
is new, there is no backwards compatibility concern. (Incidentally, I
would love to someday make a protocol change that lets users
distinguish between inserted & updated counts in INSERT ON CONFLICT,
and we could use the same facility to distinguish between
updated/deleted vs inserted in FOR PORTION OF.)

- I did lots of general cleanup in the FOR PORTION OF patch. After 52
versions and many pivots, it had accumulated some bits that didn't
belong there. I split things up a bit more as well: the TriggerData
changes have their own patch now, as do the changes to
FindFKPeriodOpers (prep for CASCADE/SET NULL/SET DEFAULT). I also ran
pgindent on everything.

Rebased to ea06263c4a.

Yours,

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com