Re: [POC]Enable tuple change partition caused by BEFORE TRIGGER - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: [POC]Enable tuple change partition caused by BEFORE TRIGGER
Date
Msg-id CAG-ACPXNynSRzFEDkd0L6--5S2=nkcsO_ekmf16HzMp+JbqSew@mail.gmail.com
Whole thread Raw
In response to Re: [POC]Enable tuple change partition caused by BEFORE TRIGGER  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [POC]Enable tuple change partition caused by BEFORE TRIGGER  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers


On Wed, 26 Aug 2020 at 22:47, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:

What this is saying to me is that we'd need to make sure to run the
final target partition's AFTER triggers, not the original target
partition.

Agreed.
 
  But I'm not 100% about running the BEFORE triggers.  Maybe
one way to address this is to check whether the BEFORE triggers in the
new target partition are clones; if so then they would have run in the
original target partition and so must not be run, but otherwise they
have to.

This will work as long as the two BEFORE ROW triggers have the same effect. Consider two situations resulting in inserting identical rows 1. row that the before row trigger has redirected to a new partition, say part2 2. a row inserted directly into the part2 - if both these rows are identical before the BEFORE ROW triggers have been applied, they should remain identical while inserting into part2. Any divergence might be problematic for the application.

--
Best Wishes,
Ashutosh

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Next
From: Tatsuro Yamada
Date:
Subject: Re: list of extended statistics on psql