Robert Haas wrote:
> On Wed, Nov 25, 2009 at 5:03 AM, Hannu Krosing <hannu@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
