Re: UPDATE/DELETE FOR PORTION OF fire FOR EACH STATEMENT more than once

From: Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>
To: Thom Brown <thom(at)linux(dot)com>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: UPDATE/DELETE FOR PORTION OF fire FOR EACH STATEMENT more than once
Date: 2026-05-04 01:14:21
Message-ID: CA+renyU_kzd-28UiMRLa1EcQqN9a8Gd48r3-vkFXUTPDBMPyRg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, May 3, 2026 at 3:50 PM Thom Brown <thom(at)linux(dot)com> wrote:
>
> Actually, I'm wrong here. It outputs all at depth 1. This would have
> been a way to implement a barrier into the function so that you can
> decide whether the trigger only fires for the original statement.
>
> So might there be a scenario where a user would wish to distinguish
> between an explicit INSERT from an INSERT generated by the temporal
> table machinery? None of the TG_* variables expose anything that would
> allow one to do this. Sure, the user could pattern match against
> current_query() and see that it really is an INSERT, but it's somewhat
> kludgy.

That's one way, but I agree it's kludgy. I have some uncommitted
patches at [1] to (1) expose the FOR PORTION OF parameters to triggers
in the C struct (2) use that info ourselves to implement CASCADE/SET
NULL/SET DEFAULT against temporal foreign keys (3) expose the same
information in PL/pgSQL TG_* variables. But those would only be set
for UPDATE/DELETE triggers, not the INSERT trigger. But maybe we
should pass them to INSERT triggers too, if the insert is the result
of an UPDATE/DELETE FOR PORTION OF? It seems a little strange, but it
would be unambiguous, and it would give useful information to users
who want to bypass triggers in that case.

[1] https://commitfest.postgresql.org/patch/5836/

Yours,

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2026-05-04 02:00:00 Report index currently being vacuumed in pg_stat_progress_vacuum
Previous Message Thom Brown 2026-05-03 22:50:13 Re: UPDATE/DELETE FOR PORTION OF fire FOR EACH STATEMENT more than once