Itagaki Takahiro wrote:
Emmanuel Cecchet <m...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
