On Sun, May 3, 2026 at 3:50 PM Thom Brown <[email protected]> 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 ~{:-) [email protected]
