| 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
| 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 |