Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2020-04-08T16:02:39Z
Lists: 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
Commits
-
psql \d: Display table where trigger is defined, if inherited
- c33869cc3bfc 13.0 landed
-
Document partitiong tables ancillary object handling some more
- cda02408f20d 12.3 landed
- 97dcd5cd1500 11.8 landed
- 8803506c411e 13.0 landed
-
Fix detaching partitions with cloned row triggers
- e26c8a6b31e9 12.3 landed
- afccd76f1cce 13.0 landed
- 0b83c47216b0 11.8 landed