On 12 May 2017 at 14:56, Amit Kapila <amit.kapil...@gmail.com> wrote: > I think it might be better to summarize all the options discussed > including what the patch has and see what most people consider as > sensible.
Yes, makes sense. Here are the options that were discussed so far for ROW triggers : Option 1 : (the patch follows this option) ---------- BR Update trigger for source partition. BR,AR Delete trigger for source partition. BR,AR Insert trigger for destination partition. No AR Update trigger. Rationale : BR Update trigger should be fired because that trigger can even modify the rows, and that can even result in partition key update even though the UPDATE statement is not updating the partition key. Also, fire the delete/insert triggers on respective partitions since the rows are about to be deleted/inserted. AR update trigger should not be fired because that required an actual update to have happened. Option 2 ---------- BR Update trigger for source partition. AR Update trigger on destination partition. No insert/delete triggers. Rationale : Since it's an UPDATE statement, only update triggers should be fired. The update ends up moving the row into another partition, so AR Update trigger should be fired on this partition rather than the original partition. 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. Option 4 -------- BR-AR update triggers for source partition BR-AR insert triggers for destination partition Rationale : Since it is an update statement, both BR and AR UPDATE trigger should be fired on original partition. Since update is converted to delete+insert, the corresponding triggers should be fired, but since we already are firing UPDATE trigger on original partition, skip delete triggers, otherwise both UPDATE and DELETE triggers would get fired on the same partition. ---------------- For statement triggers, I think it should be based on the documentation recently checked in for partitions in general. + A statement that targets a parent table in a inheritance or partitioning + hierarchy does not cause the statement-level triggers of affected child + tables to be fired; only the parent table's statement-level triggers are + fired. However, row-level triggers of any affected child tables will be + fired. Based on that, for row movement as well, the trigger should be fired only for the table referred in the UPDATE statement, and not for any child tables, or for any partitions to which the rows were moved. The doc in this row-movement patch also matches with this behaviour. -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers