Re: Partitioning option for COPY

Itagaki Takahiro wrote:
> Emmanuel Cecchet <manu@asterdata.com> wrote:
>
>   
>> I guess the problem of handling user triggers is still open.
>> If we allow triggers on partitions, badly written logic could lead to 
>> infinite loops in routing.
>>     
> Infinite loops are not a partition-related problem, no?
> We can also find infinite loops in user defined functions,
> recursive queries, etc. I think the only thing we can do for it
> is to *stop* loops instead of prevention, like max_stack_depth.
>   
I was thinking a trigger on child1 updating the partition key forcing 
the tuple to move to child2. And then a trigger on child2 updating the 
key again to move the tuple back to child1. You end up with an infinite 
loop.
>> With the current proposed implementation, would it be 
>> possible to define a view using child tables?
>>     
>
> No, if you mean using a partition-view. I'm thinking we are moving
> our implementation of partitioning from view-based to built-in feature.
> Do you have any use-cases that requires view-based partitioning?
> Was the inheritance-based partitioning not enough for it?
>   
Nevermind, I was thinking about the implications of materialized views 
but Postgres does not have materialized views!

I have other questions related to create table but I will post them in 
the 'syntax for partitioning' thread.

Thanks
Emmanuel

-- 
Emmanuel Cecchet
Aster Data
Web: http://www.asterdata.com