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

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

Heh.

> 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.

Well, then we lose the property Alvaro wanted, namely that if an
application chooses to insert directly into a partition, that's
just an optimization that changes no behavior (as long as it picked
the right partition). Maybe this can be dodged by propagating
parent trigger definitions to the children, but it's going to be
complicated I'm afraid.

regards, tom lane