| From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
|---|---|
| To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Subject: | Re: Remove mention in docs that foreign keys on partitioned tables are not supported |
| Date: | 2018-05-02 13:17:23 |
| Message-ID: | CAFjFpRdBQiGOxtSURpXLwskK6GTn_uROP9_JOBN3EB80RCEzag@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 2, 2018 at 11:56 AM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2018-05-02 13:28:58 | Re: Should we add GUCs to allow partition pruning to be disabled? |
| Previous Message | John Naylor | 2018-05-02 12:19:51 | Re: inconsistency and inefficiency in setup_conversion() |