Robert Haas wrote:
On Wed, Nov 25, 2009 at 5:03 AM, Hannu Krosing <ha...@2ndquadrant.com> wrote:
I'd propose that triggers on both parent table and selected child are
executed.
I was thinking we should make the partitioning decision FIRST, before
any triggers are fired, and then fire only those triggers relevant to
the selected partition. If the BEFORE triggers on the partition
modify the tuple in a way that makes it incompatible with the table
constraints on that partition, the insert (or update) fails.
Firing triggers on more than one table is pretty substantially
incompatible with what we do elsewhere and I'm not clear what we get
in exchange. What is the use case for this?
I don't have a use case for this but I was puzzled with that when I had
to implement trigger support in COPY with partitioning.
I came to the same conclusion as you and made the operation fail if the
trigger was trying to move the tuple to another partition. However, I
had a problem with after row triggers that I had to call synchronously
to be able to detect the change. We will need something to tell us that
an after row trigger did not mess with the routing decision.
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
