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? For example, in the above trigger function, we can maintain a count in some table (e.g how many time delete trigger got executed) and after test over we can verify the same. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
