Re: Partitioning feature ...

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