On 2018-Jun-07, Ashutosh Bapat wrote: > On Thu, Jun 7, 2018 at 10:58 AM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote:
> > I don't understand why you think it's too troublesome to let the users > > know that there is some way to use BR triggers with partitioning. We > > didn't do that for indexes, for example, before PG 11 introduced the > > ability to create them on partitioned tables. > > By looking at the index keys it's easy to decide whether the two > indexes are same. When we add an index on a partitioned table in v11, > we skip creating an index on the partition if there exists an index > similar to the one being created. So, a user can have indexes on > partitions created in v10, upgrade to v11 and create an index on the > partitioned table. Nothing changes. But that's not true for a trigger. > It's not easy to check whether two triggers are same or not unless the > underlying function is same. User may or may not be using same trigger > function for all the partitions, which is more true, if the column > order differs between partitions. So, if the user has created triggers > on the partitions in v10, upgrades to v11, s/he may have to drop them > all and recreate the trigger on the partitioned table. Actually, the column order doesn't matter for a trigger function, because these don't refer to columns by number but by name. So unless users write trigger functions in C and use hardcoded column numbers (extremely unlikely), I think this is not an issue. In other words, in the interesting cases the trigger functions are the same for all partitions -- therefore upgrading from separate per-partition triggers to one master trigger in the partitioned table is not going to be that difficult, ISTM. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
