On Thu, Jun 7, 2018 at 10:58 AM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2018/06/07 14:17, Ashutosh Bapat wrote: >>> that is, users can find out about that feature by themselves by >>> trying it out? >> >> I didn't understand that part. >> >> Probably we just say that BEFORE ROW triggers are not supported on a >> partitioned table. It's good enough not to suggest it ourselves. If >> users find out that they can create triggers on partitions and use it >> that way, they may or may not have to change their implementation >> later when we start supporting those. But then we didn't suggest that >> they do it that way. >
> 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. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
