From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Dominique Devienne <ddevienne(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: How to avoid Trigger ping/pong / infinite loop |
Date: | 2023-02-16 17:58:45 |
Message-ID: | 4790b5f7-f6ce-8399-78ad-398e13eb4b6f@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2/16/23 09:43, Dominique Devienne wrote:
> Hi. I have a large "legacy" code base that write information necessary
> for Row-Level-Security in a highly denormalized custom had-hoc text
> format for values, in key-value pairs in a table, which would be either
> impossible or too slow to base any RLS policy on. The values are
> basically lists or maps, depending on the key.
"... which would be either impossible or too slow to base any RLS policy
on."
and
"At time point, changing the legacy code base is not really an option..."
seem to be at odds.
So is the current system working or not?
>
> I also have new code that will read and write that same information, but
> would much prefer to use a normalized data model, the same one that
> would be appropriate for efficient RLS.
>
> So I'm wondering if I can have my cake and eat it too, by synchronizing
> the normalized and denormalized information (necessarily duplicated
> then), server-side via triggers, w/o running into infinite loops.
A VIEW over both sets of data?
>
> 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).
>
> Any thoughts? --DD
>
> PS: At time point, changing the legacy code base is not really an option...
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2023-02-16 18:02:00 | Re: Support logical replication of DDLs |
Previous Message | Alvaro Herrera | 2023-02-16 17:53:05 | Re: Support logical replication of DDLs |