From: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, amitlangote09(at)gmail(dot)com |
Subject: | Re: partitioned tables referenced by FKs |
Date: | 2019-03-29 19:39:53 |
Message-ID: | 6c6bcb5b-34a2-80ea-07d7-58f1eb7f4a0a@redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Alvaro,
On 3/28/19 2:59 PM, Alvaro Herrera wrote:
> I ended up revising the dependencies that we give to the constraint in
> the partition -- instead of giving it partition-type dependencies, we
> give it an INTERNAL dependency. Now when you request to drop the
> partition, it says this:
>
> create table pk (a int primary key) partition by list (a);
> create table fk (a int references pk);
> create table pk1 partition of pk for values in (1);
>
> alvherre=# drop table pk1;
> ERROR: cannot drop table pk1 because other objects depend on it
> DETAIL: constraint fk_a_fkey on table fk depends on table pk1
> HINT: Use DROP ... CASCADE to drop the dependent objects too.
>
> If you do say CASCADE, the constraint is dropped. Not really ideal (I
> would prefer that the drop is prevented completely), but at least it's
> not completely bogus. If you do "DROP TABLE pk", it works sanely.
> Also, if you DETACH the partition that pg_depend row goes away, so a
> subsequent drop of the partition works sanely.
>
> Fixed the psql issue pointed out by Amit L too.
>
I ran my test cases for this feature, and havn't seen any issues.
Therefore I'm marking 1877 as Ready for Committer. If others have
additional feedback feel free to switch it back.
Best regards,
Jesper
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2019-03-29 19:41:48 | Re: PostgreSQL pollutes the file system |
Previous Message | Christoph Berg | 2019-03-29 19:38:54 | Re: PostgreSQL pollutes the file system |