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

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: [POC]Enable tuple change partition caused by BEFORE TRIGGER
Дата
Msg-id 20200827160955.GA1665@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: [POC]Enable tuple change partition caused by BEFORE TRIGGER  (Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>)
Список pgsql-hackers
On 2020-Aug-27, Ashutosh Bapat wrote:

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

> >   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.

Well, that's why I talk about the trigger being "clones" -- with that
term, I mean that their definitions have been inherited from a
definition in some ancestor partitioned table, and so they must be
identical in the partitions.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Borisov
Дата:
Сообщение: Re: [PATCH] Covering SPGiST index
Следующее
От: Mark Dilger
Дата:
Сообщение: Deprecating postfix and factorial operators in PostgreSQL 13