On Wed, May 17, 2017 at 4:05 PM, Dilip Kumar <dilipbal...@gmail.com> wrote: > On Wed, May 17, 2017 at 3:15 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> Earlier I thought that option1 is better but later I think that this >>> can complicate the situation as we are firing first BR update then BR >>> delete and can change the row multiple time and defining such >>> behaviour can be complicated. >>> >> >> If we have to go by this theory, then the option you have preferred >> will still execute BR triggers for both delete and insert, so input >> row can still be changed twice. > > Yeah, right as per my theory above Option3 have the same problem. > > But after putting some more thought I realised that only for "Before > Update" or the "Before Insert" trigger row can be changed. >
Before Row Delete triggers can suppress the delete operation itself which is kind of unintended in this case. I think without the user being aware it doesn't seem advisable to execute multiple BR triggers. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
