From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: FOR EACH ROW triggers on partitioned tables |
Date: | 2018-02-15 07:25:54 |
Message-ID: | 77d52cfc-76d4-91ea-da90-ff2dc2db6f6b@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018/02/15 6:26, Alvaro Herrera wrote:
> Another option is to rethink this feature from the ground up: instead of
> cloning catalog rows for each children, maybe we should have the trigger
> lookup code, when running DML on the child relation (the partition),
> obtain trigger entries not only for the child relation itself but also
> for its parents recursively -- so triggers defined in the parent are
> fired for the partitions, too. I'm not sure what implications this has
> for constraint triggers.
>
> The behavior should be the same, except that you cannot modify the
> trigger (firing conditions, etc) on the partition individually -- it
> works at the level of the whole partitioned table instead.
Do you mean to fire these triggers only if the parent table (not a child
table/partition) is addressed in the DML, right? If the table directly
addressed in the DML is a partition whose parent has a row-level trigger,
then that trigger should not get fired I suppose.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2018-02-15 08:20:00 | Re: Cached/global query plans, autopreparation |
Previous Message | Masahiko Sawada | 2018-02-15 06:28:39 | Re: autovacuum: change priority of the vacuumed tables |