On Thu, Jun 14, 2018 at 9:45 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: >> It sounds like you want to try to hide from users the fact that they >> can create triggers on the individual partitions. > > No. I never said that in my mails (see [1], [2]) I object to the > explicit suggestion that they can/should create BEFORE ROW triggers on > partitions since those are not supported on the partitioned table. > >> I think that's the >> wrong approach. First of all, it's not going to work, because people >> are going to find out about it and do it anyway. Secondly, the >> documentation's job is to tell you about the system's capabilities, >> not conceal them from you. > > Neither is documentation's job to "suggest" something that can lead to > problems in future.
Well, perhaps what this boils down to is that I don't agree that it can lead to problems in the future. If the user creates a trigger on each partition, whether they are all the same or some are different from others, they can stick with that configuration in future releases, too. I don't think we're going to remove the ability to have separate triggers on each partition; we're just going to add, as an additional possibility, the ability to have a trigger on the partitioned table that cascades to the individual partitions. It's true that if people want to get the benefit of that feature, they'll have to change the configuration, but so what? That's true of many new features, and I don't think it's right to characterize that as a problem. 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. I think that the existing wording is fine and there's really no need to change anything. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company