Re: Remove mention in docs that foreign keys on partitioned tables are not supported

On Mon, Jun 4, 2018 at 4:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Jun 4, 2018 at 1:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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