On Wed, 2009-11-25 at 11:30 -0500, Tom Lane wrote: > It seems like the easiest way to resolve this without weird corner > cases is to say that we fire triggers belonging to the parent table. > The individual partition child tables either shouldn't have triggers > at all, or we should restrict the cases in which those are considered > applicable.
Agreed. maybe allow only ROW-level AFTER triggers (for logging late arrivals and updates on tables partitioned on time for example ) > As an example, what are you going to do with statement-level triggers? > Fire them for *every* child whether it receives a row or not? Doesn't > seem like the right thing. > > Again, this solution presupposes an explicit concept of partitioned > tables within the system... For explicit partitioned tables with hidden partitions it is of course best to not add extra effort for allowing triggers to be defined on those (hidden) partitions. If the partition tables are visible, some trigger support would be good. > regards, tom lane -- Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
