On Wed, May 24, 2017 at 2:47 PM, Amit Khandekar <amitdkhan...@gmail.com> wrote: > On 18 May 2017 at 16:52, Amit Kapila <amit.kapil...@gmail.com> wrote: >> 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. > > By now, majority of the opinions have shown that they do not favour > two triggers getting fired on a single update. Amit, do you consider > option 2 as a valid option ? >
Sounds sensible to me. > That is, fire only UPDATE triggers. BR on > source partition, and AR on destination partition. Do you agree that > firing BR update trigger is essential since it can modify the row and > even prevent the update from happening ? > Agreed. Apart from above, there is one open issue [1] related to generating an error for concurrent delete of row for which I have mentioned some way of getting it done, do you want to try that option and see if you face any issue in making the progress on that lines? -- 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
