Itagaki Takahiro wrote:
I just edited a wiki page for this discussion.
I hope it can be a help.
http://wiki.postgresql.org/wiki/Table_partitioning
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. In the case of COPY, an after statement
trigger could change all the routing decisions taken for each row. I am
not sure what the semantic should be if you have triggers defined on the
parent and child tables. Which triggers do you fire if the insert is on
the parent table but the tuple ends up in a child table?
If the new implementation hides the child tables, it might be safer to
not allow triggers on child tables altogether and use the parent table
as the single point of entry to access the partition (and define
triggers). With the current proposed implementation, would it be
possible to define a view using child tables?
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
