On Mon, Jun 18, 2018 at 11:28 AM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Mon, Jun 18, 2018 at 10:21 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: >> Attached is v2 version of the patch. It contains the above >> trigger-related issue fixed. >> >> The updated tuple is passed back using the existing newslot parameter >> of GetTupleForTrigger(). When ExecBRDeleteTriggers() is called using a >> new epqslot parameter, it means caller wants to skip the trigger >> execution, because the updated tuple needs to be again checked for >> constraints. I have added comments of this behaviour in the >> ExecBRDeleteTriggers() function header. >> > > Thanks for the updated patch. I have verified the BR trigger > behaviour, its working fine with the patch. > > + CREATE FUNCTION func_footrg() RETURNS TRIGGER AS $$ > + BEGIN > + RETURN OLD; > + END $$ LANGUAGE PLPGSQL; > + CREATE TRIGGER footrg_ondel BEFORE DELETE ON footrg1 > + FOR EACH ROW EXECUTE PROCEDURE func_footrg(); > > Should we also create a test case where we can verify that some > unnecessary or duplicate triggers are not executed? >
I am not sure how much value we will add by having such a test. In general, it is good to have tests that cover various aspects of functionality, but OTOH, we have to be careful to not overdo it. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
