Yes, there is a good reason. As a trigger can update the tuple value,
this can change the routing decision. If you have a user trigger that
tries to change the key value after the partition choice has been made,
this will lead to an integrity constraint violation which is probably
not what the user expects.
Note that user triggers with partitions will be tricky anyway
(regardless of how partitioning is implemented, that is with triggers or
not). If 2 partitions have user triggers that update the key value to
bounce the tuple to the other partition you may end up with an infinite
loop.
I am not sure what the semantic of statement triggers (still user
triggers) should be on partitioned tables.
We will probably have to come up with restrictions on triggers so that
they can only be applied to the parent table and not on child tables to
prevent nasty issues.
Emmanuel
Tom Lane wrote:
> In the case of the FK triggers, it's intentional (and maybe even
> documented) that users should be able to place their own triggers before
> or after the FK triggers. Is there a good reason why partitioning
> triggers should be different? If there is, maybe the feature shouldn't
> be implemented via triggers in the first place.
>
> regards, tom lane
>
--
Emmanuel Cecchet
Aster Data Systems
Web: http://www.asterdata.com
