On Wed, Jun 6, 2018 at 7:51 AM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
> On Tue, Jun 5, 2018 at 10:38 PM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
>
>> - BEFORE row triggers are not supported
>
> I think this is fine. The existing wording suggests that the user
> creates the triggers on the partitioned table, and that will be
> supported always, which can lead to problems. With this description,
> if the user finds out that BEFORE triggers are supported on partitions
> and creates those, and we implement something to support those on
> partitioned table, s/he will have to change the implementation
> accordingly.
It sounds like you want to try to hide from users the fact that they
can create triggers on the individual partitions. 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. Third, any speculation about what upgrade
problems people might have in the future is just that: speculation.
As the saying goes, it's tough to make predictions, especially about
the future.
To put that another way, if we really think nobody should do this, we
should prohibit it, not leave it out of the documentation. But I
think prohibiting it would be a terrible idea: it would break upgrades
from existing releases and inconvenience users to no good purpose.
Very few, if any, users say, well, I don't really need a trigger on
this table, but PostgreSQL is really quite a bit faster than I need it
to be, so I think I'll add one anyway just to slow things down. We
should assume that anyone who wants a BEFORE trigger has a good reason
for wanting it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
