On 2018-Jun-04, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > On 2018-Jun-04, Tom Lane wrote:
> >> ... why doesn't the same problem apply to AFTER triggers that are attached
> >> to the inheritance parent?
>
> > With a BEFORE trigger, running the trigger might change the target
> > partition, which has the potential for all kinds of trouble.
>
> Got it. That seems like not just an implementation restriction, but
> a pretty fundamental issue.
>
> Could we solve it by saying that triggers on partitioned tables aren't
> allowed to change the partitioning values? (Or at least, not allowed
> to change them in a way that changes the target partition.)
Yes, that would be one way forward. In fact, IIUC what happens today if
you remove the restriction (as Amit tested and reported upthread[1]) is
that this already causes an error, because tuple routing is not re-done
after BEFORE triggers are run.
I was thinking it would be good to leave the option open (i.e. forbid
BEFORE triggers altogether) so that in the future we could implement
that case too, and avoid a backwards-incompatible behavior change.
Thinking about it again, this may not be a problem: if you write a
trigger that works (it doesn't change the target partition) then when
forward-porting it to a version that does allow the target partition to
change, your trigger doesn't change behavior. So maybe it's okay to
remove the restriction. I'll test more tomorrow.
[1] https://postgr.es/m/1824bda1-0c47-abc4-8b97-e37414c52f6c@lab.ntt.co.jp
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services