Re: [POC]Enable tuple change partition caused by BEFORE TRIGGER

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: [POC]Enable tuple change partition caused by BEFORE TRIGGER
Дата
Msg-id CAG-ACPXNynSRzFEDkd0L6--5S2=nkcsO_ekmf16HzMp+JbqSew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [POC]Enable tuple change partition caused by BEFORE TRIGGER  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [POC]Enable tuple change partition caused by BEFORE TRIGGER  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Следующее
От: Tatsuro Yamada
Дата:
Сообщение: Re: list of extended statistics on psql