On Wed, Nov 25, 2009 at 9:21 AM, Emmanuel Cecchet <manu@asterdata.com> wrote:
> 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.
*scratches head*
I'm confused. Only a BEFORE ROW trigger can possibly change
anything... the return value of an AFTER ROW trigger is ignored.
...Robert