From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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> |
Subject: | Re: Remove mention in docs that foreign keys on partitioned tables are not supported |
Date: | 2018-06-06 08:08:14 |
Message-ID: | 526a1381-138d-3213-9578-e15c06a89e24@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018/06/06 2:08, Alvaro Herrera wrote:
> On 2018-Jun-05, Amit Langote wrote:
>
>> On 2018/06/05 16:41, Ashutosh Bapat wrote:
>>> On Tue, Jun 5, 2018 at 1:07 PM, Amit Langote
>>> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>>> On 2018/06/05 1:25, Alvaro Herrera wrote:
>>>>> In the meantime, my inclination is to fix the documentation to point out
>>>>> that AFTER triggers are allowed but BEFORE triggers are not.
>>>>
>>>> Wasn't that already fixed by bcded2609ade6?
>
> Ah, yes, so it's already OK.
>
>>> Thought correct that suggestion is problematic for upgrades. Probably
>>> users will create triggers using same function on all the partitions.
>>> After the upgrade when we start supporting BEFORE TRIGGER on
>>> partitioned table, the user will have to drop these triggers and
>>> create one trigger on the partitioned table to have the trigger to be
>>> applicable to the new partitions created.
>>
>> Hmm yes, maybe there is scope for rewording then.
>
> Reading that subsection in its entirety, I'm not sure how to do better
> -- it's all about restrictions that currently exist and we think we
> could do better in the future, with the exception of the one about an
> UPDATE/DELETE not seeing the updated version after a row migrating to
> another partition. One idea would be to split it into its own list of
> issues; something like:
>
> "The following limitations apply, and might be lifted in the future:
> - no way to create exclusion constraint
> - foreign keys cannot refer to partitioned tables
> - BEFORE row triggers are not supported
>
> The following caveat applies to partitioned tables:
> - When an UPDATE causes a row to move ..."
>
> In other words, make a distinction of things we expect to change soon
> (which might be too optimistic), vs. others we don't expect to change.
>
> Or we could leave it alone; any behavior change would be called out in
> the future version's release notes anyway. This is what I propose.
That works for me. :)
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2018-06-06 08:44:07 | Re: I'd like to discuss scaleout at PGCon |
Previous Message | Amit Langote | 2018-06-06 08:00:55 | Re: BUG #15212: Default values in partition tables don't work as expected and allow NOT NULL violation |