On 2018/02/16 6:55, Alvaro Herrera wrote: > Amit Langote wrote: >> On 2018/02/15 6:26, Alvaro Herrera wrote: >>> Another option is to rethink this feature from the ground up: instead of >>> cloning catalog rows for each children, maybe we should have the trigger >>> lookup code, when running DML on the child relation (the partition), >>> obtain trigger entries not only for the child relation itself but also >>> for its parents recursively -- so triggers defined in the parent are >>> fired for the partitions, too. I'm not sure what implications this has >>> for constraint triggers. >>> >>> The behavior should be the same, except that you cannot modify the >>> trigger (firing conditions, etc) on the partition individually -- it >>> works at the level of the whole partitioned table instead. >> >> Do you mean to fire these triggers only if the parent table (not a child >> table/partition) is addressed in the DML, right? If the table directly >> addressed in the DML is a partition whose parent has a row-level trigger, >> then that trigger should not get fired I suppose. > > No, I think that would be strange and cause data inconsistencies. > Inserting directly into the partition is seen as a performance > optimization (compared to inserted into the partitioned table), so we > don't get to skip firing the triggers defined on the parent because the > behavior would become different. In other words, the performance > optimization breaks the database.
OK, that makes sense. Thanks, Amit
