On Sat, Jun 16, 2018 at 9:29 AM, Robert Haas <robertmh...@gmail.com> wrote: > > By that logic, we should not have suggested that anyone use table > inheritance, because they would have to change their configuration > when we implemented table partitioning. Indeed, switching from table > inheritance to table partitioning is much more intrusive than dropping > triggers on individual partitions and adding one on the partitioned > table. The latter only requires DDL on existing objects, but the > former requires creating entirely new objects and moving all of your > data.
That's a wrong comparison. Inheritance based partitioning works even after declarative partitioning feature is added. So, users can continue using inheritance based partitioning if they don't want to move to declarative partitioning. That's not true here. A user creates a BEFORE ROW trigger on each partition that mimics partitioned table level BEFORE ROW trigger. The proposed BEFORE ROW trigger on partitioned table will cascade the trigger down to each partition. If that fails to recognize that there is already an equivalent trigger, a partition table will get two triggers doing the same thing silently without any warning or notice. That's fine if the trigger changes the salaries to $50K but not OK if each of those increases salary by 10%. The database has limited ability to recognize what a trigger is doing. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company