On Wed, May 24, 2017 at 2:47 PM, Amit Khandekar <amitdkhan.pg@gmail.com> wrote:
> On 18 May 2017 at 16:52, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> On Wed, May 17, 2017 at 4:05 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
>>> On Wed, May 17, 2017 at 3:15 PM, Amit Kapila <amit.kapila16@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
