From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Dominique Devienne <ddevienne(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: How to avoid Trigger ping/pong / infinite loop |
Date: | 2023-02-16 19:22:04 |
Message-ID: | CAKFQuwZb+jY2A_j2MjJszBmn8YPW1imwnjefGtjR2=1NiNqdAA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Feb 16, 2023 at 10:43 AM Dominique Devienne <ddevienne(at)gmail(dot)com>
wrote:
> Are there techniques for situations like this?
>
> This question is not too far from my earlier question, in the sense that a
> trigger would need to know the context in which it was triggered, i.e.
> directly (then update the other model), or indirectly (don't update, the
> change is boomerang'ing around from our own change).
>
As with the other question - a trigger does not know how the
insert/update/delete action came into existence, it is only reacting to the
fact that a given row is being added/updated/removed from its table. You
might be able to expend a non-trivial amount of effort trying to figure out
schemes whereby such information can be inferred but you are fighting the
system.
PS: At time point, changing the legacy code base is not really an option...
>
Then maybe you need to design the new system to behave in a manner similar
to the legacy system for the stuff they share in common. You can then have
a uni-directional trigger going from legacy to modern.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2023-02-16 19:28:02 | Re: Vacuum full issue |
Previous Message | Jonathan S. Katz | 2023-02-16 19:01:52 | Re: Support logical replication of DDLs |