Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> This kind of inconsistency is what I wanted to avoid. One of the
> guiding principles here was that a partitioned table behaves just like a
> regular table does; in particular, inserting directly into a partition
> is an application-level optimization that must behave exactly like it
> would if the insert had gone into its parent table (unless the user
> explicitly makes it not so). If we make an insertion into the partition
> *not* fire the trigger that would have been fired by inserting into the
> partitioned table, that's a bug. I couldn't see a way to have the
> BEFORE trigger handle that nicely, so I decided to punt on that feature.
Reasonable, but ...
> In the meantime, my inclination is to fix the documentation to point out
> that AFTER triggers are allowed but BEFORE triggers are not.
... why doesn't the same problem apply to AFTER triggers that are attached
to the inheritance parent?
regards, tom lane
