Re: Referential Integrity Checks with Statement-level Triggers - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Referential Integrity Checks with Statement-level Triggers
Date
Msg-id CA+hUKG+1UMa7TVAYdhH+u6uysS6ybsCA4RpxGAUGDFPVdranGQ@mail.gmail.com
Whole thread Raw
In response to Re: Referential Integrity Checks with Statement-level Triggers  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: Referential Integrity Checks with Statement-level Triggers  (Corey Huinker <corey.huinker@gmail.com>)
List pgsql-hackers
On Tue, Feb 26, 2019 at 5:41 AM Corey Huinker <corey.huinker@gmail.com> wrote:
>> In order to avoid per-row calls of the constraint trigger functions, we could
>> try to "aggregate" the constraint-specific events somehow, but I think a
>> separate queue would be needed for the constraint-specific events.
>>
>> In general, the (after) triggers and constraints have too much in common, so
>> separation of these w/o seeing code changes is beyond my imagination.
>
> Yeah, there's a lot of potential for overlap where a trigger could "borrow" an RI tuplestore or vice versa.
>
> The people who expressed opinions on nuking triggers from orbit (it's the only way to be sure) have yet to offer up
anyguidance on how to proceed from here, and I suspect it's because they're all very busy getting things ready for v12.
Idefinitely have an interest in working on this for 13, but I don't feel good about striking out on my own without
theirinput. 

Very interesting thread, but the current patch has been through two
CFs without comments or new patches, so I'm going to mark it "Returned
with feedback".  I hope all this discussion will trigger more research
in this space.

--
Thomas Munro
https://enterprisedb.com



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Avoid full GIN index scan when possible
Next
From: Thomas Munro
Date:
Subject: Re: [PATCH] Improve performance of NOTIFY over many databases (issueblocking on AccessExclusiveLock on object 0 of class 1262 of database 0)