On 2018-Jun-04, Tom Lane wrote: > Alvaro Herrera <alvhe...@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-e37414c52...@lab.ntt.co.jp -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
