From: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: partitioned tables referenced by FKs |
Date: | 2019-03-27 14:22:21 |
Message-ID: | d70b6616-a4fd-3fc8-ae27-5907496fc535@redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 3/26/19 5:39 PM, Alvaro Herrera wrote:
>>> As I said before, I'm thinking of getting rid of the whole business of
>>> checking partitions on the referenced side of an FK at DROP time, and
>>> instead jut forbid the DROP completely if any FKs reference an ancestor
>>> of that partition.
>>
>> Will that allow `DROP TABLE parted_pk CASCADE` to succeed even if
>> partitions still contain referenced data? I suppose that's the example
>> you cited upthread as a bug that remains to be solved.
>
> That's the idea, yes, it should do that: only allow a DROP of a
> partition referenced by an FK if the topmost constraint is also being
> dropped. Maybe this means I need to get rid of 0002 completely. But I
> haven't got to doing that yet.
>
I think that is ok, if doc/src/sgml/ref/drop_table.sgml is updated with
a description of how CASCADE works in this scenario.
Best regards,
Jesper
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-03-27 14:23:06 | Re: PostgreSQL pollutes the file system |
Previous Message | Tomas Vondra | 2019-03-27 14:20:05 | Re: PostgreSQL pollutes the file system |