On Mon, Jun 4, 2018 at 4:50 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Jun 4, 2018 at 1:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> 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.) > >> That seems like a somewhat-unfortunate restriction. > > Perhaps, but I'm having a hard time wrapping my mind around what the > semantics ought to be. If a trigger on partition A changes the keys > so that the row shouldn't have gone into A at all, what then? That > trigger should never have fired, eh?
Causality is for wimps. :-) I agree that it's weird if you think about a partition, but it's a lot less strange if you think about a partitioned table. If we're running the trigger before tuple routing has been done, then we ought to be able to change the results of tuple routing. I think, in general, that we should try to pick semantics that make a partitioned table behave like an unpartitioned table, provided that all triggers are defined on the partitioned table itself. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
