Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables
Date
Msg-id 20200408160239.GA13987@alvherre.pgsql
Whole thread Raw
In response to DETACH PARTITION and FOR EACH ROW triggers on partitioned tables  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables  (Justin Pryzby <pryzby@telsasoft.com>)
Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2020-Apr-08, Justin Pryzby wrote:

> This seems to be a bug in master, v12, and (probably) v11, where "FOR EACH FOR"
> was first allowed on partition tables (86f575948).
> 
> I thought this would work like partitioned indexes (8b08f7d48), where detaching
> a partition makes its index non-inherited, and attaching a partition marks a
> pre-existing, matching partition as inherited rather than creating a new one.

Hmm.  Let's agree to what behavior we want, and then we implement that.
It seems to me there are two choices:

1. on detach, keep the trigger but make it independent of the trigger on
parent.  (This requires that the trigger is made dependent on the
trigger on parent, if the table is attached as partition again;
otherwise you'd end up with multiple copies of the trigger if you
detach/attach multiple times).

2. on detach, remove the trigger from the partition.

I think (2) is easier to implement, but (1) is the more convenient
behavior.

(The current behavior is obviously a bug.)

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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [PATCH] Incremental sort
Next
From: Erik Rijkers
Date:
Subject: warning in partioning code