Re: How to avoid Trigger ping/pong / infinite loop

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.

In response to

Responses

Browse pgsql-general by date

  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