Re: Remove mention in docs that foreign keys on partitioned tablesare not supported - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Remove mention in docs that foreign keys on partitioned tablesare not supported
Date
Msg-id CAFjFpRdBQiGOxtSURpXLwskK6GTn_uROP9_JOBN3EB80RCEzag@mail.gmail.com
Whole thread Raw
In response to Re: Remove mention in docs that foreign keys on partitioned tablesare not supported  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Remove mention in docs that foreign keys on partitioned tablesare not supported  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, May 2, 2018 at 11:56 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> But one could very well argue that BEFORE ROW triggers on the
> parent should run before performing the tuple routing and not be cloned to
> individual partitions, in which case the result would not have been the
> same.  Perhaps that's the motivation behind leaving this to be considered
> later.

+1 for that. We should associate before row triggers with the
partitioned table and not with the partitions. Those should be
executed before tuple routing (for that partition level) kicks in. But
then that would be asymetric with AFTER row trigger behaviour. From
this POV, pushing AFTER row triggers to the individual partitions
doesn't look good.

Other question that comes to my mind is what happens when rows are
inserted into a partition directly. Do we execute BEFORE trigger on
the partitioned table?

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: inconsistency and inefficiency in setup_conversion()
Next
From: Alvaro Herrera
Date:
Subject: Re: Should we add GUCs to allow partition pruning to be disabled?