On Fri, May 12, 2017 at 4:17 PM, Amit Khandekar <amitdkhan...@gmail.com> wrote: > Option 3 > -------- > > BR, AR delete triggers on source partition > BR, AR insert triggers on destination partition. > > Rationale : > Since the update is converted to delete+insert, just skip the update > triggers completely.
+1 to option3 Generally, BR triggers are used for updating the ROW value and AR triggers to VALIDATE the row or to modify some other tables. So it seems that we can fire the triggers what is actual operation is happening at the partition level. For source partition, it's only the delete operation (no update happened) so we fire delete triggers and for the destination only insert operations so fire only inserts triggers. That will keep the things simple. And, it will also be in sync with the actual partition level delete/insert operations. We may argue that user might have declared only update triggers and as he has executed the update operation he may expect those triggers to get fired. But, I think this behaviour can be documented with the proper logic that if the user is updating the partition key then he must be ready with the Delete/Insert triggers also, he can not rely only upon update level triggers. 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. -- Regards, Dilip Kumar 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
