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 по дате отправления: