Re: Triggers should work in isolation, with a final conflict detection step - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Triggers should work in isolation, with a final conflict detection step
Date
Msg-id CAKFQuwYo6+t6+1PyaHqs5jsUK-JvzTJafs51N+mEtd0o5Li7Rg@mail.gmail.com
Whole thread Raw
In response to Triggers should work in isolation, with a final conflict detection step  (Gianluca Calcagni <gclazio@hotmail.com>)
List pgsql-hackers
On Sunday, July 31, 2022, Gianluca Calcagni <gclazio@hotmail.com> wrote:

The real drawback is that such approach is forgoing the natural principle of "separation of concerns"! I have been looking into using trigger frameworks to solve this problem, but there is no trigger framework that is able to meet my main expectations: in short, isolation and conflict detection.

You may notice that I took inspiration from GIT for most of the concepts above (e.g. "isolation" actually means "forking").

I realize that this is a huge request,

So install a single c-language trigger function that does all of that and provide some functions to manage adding delegation commands in user-space.  Make it all work with create extension.  Users will have to adhere to the guidelines suggested.

I am against having core incorporate such code into the main project.  The benefits/cost_complexity ratio is too small.

IOW, I suspect the only realistic way this gets into core is if you, its champion, pay to have it developed, but even then I don’t think we should accept such a feature even if it was well written.  So if you go that route it should leverage extension mechanisms.  We may add some code hooks though if those are requested and substantiated.

David J.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Typo in pg_db_role_setting.h
Next
From: Japin Li
Date:
Subject: Re: Typo in pg_db_role_setting.h