Re: dropping partitioned tables without CASCADE

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: Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: dropping partitioned tables without CASCADE
Date: 2017-03-02 06:21:13
Message-ID: CAFjFpRemujuWj07RGHaPkiLNEhC71OBNixbhXLXL0Cqe1bk38g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>
>> Isn't list_range_parted multilevel partitioned table. It gets dropped
>> in the testcases. So, I guess, we already have a testcase there.
>
> I thought Simon meant the test case where a partition that is itself
> partitioned is dropped. At least that's what I took from "... fails *on*
> partition that has partitions". So in the example I posted, drop table p1.

Ok. Thanks for the explanation.

>
> Anyway, there might be the confusion that *only* the root level
> partitioned table is of RELKIND_PARTITIONED_TABLE. That's not true - any
> partitioned table (even one that's a partition) is of that relkind. So
> the condition in the call to StoreCatalogInheritance1() is correct. The
> following hunk:
>
> @@ -10744,7 +10756,9 @@ CreateInheritance(Relation child_rel, Relation
> parent_rel)
> StoreCatalogInheritance1(RelationGetRelid(child_rel),
> RelationGetRelid(parent_rel),
> inhseqno + 1,
> - catalogRelation);
> + catalogRelation,
> + parent_rel->rd_rel->relkind ==
> + RELKIND_PARTITIONED_TABLE);
>
> Thanks,
> Amit
>
>

I agree.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Khandekar 2017-03-02 06:23:24 Re: UPDATE of partition key
Previous Message Andres Freund 2017-03-02 06:19:30 Re: PATCH: two slab-like memory allocators