Re: Partitioning option for COPY

Itagaki Takahiro wrote:
> Emmanuel Cecchet <manu(at)asterdata(dot)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