Re: [HACKERS] dropping partitioned tables without CASCADE

On Mon, Feb 27, 2017 at 8:08 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> On 2017/02/26 5:30, Simon Riggs wrote:
>> On 23 February 2017 at 16:33, Simon Riggs <simon@2ndquadrant.com> wrote:
>>
>>>  I'll be happy to review
>>
>> Patch looks OK so far, but fails on a partition that has partitions,
>> probably because of the way we test relkind in the call to
>> StoreCatalogInheritance1().
>
> Thanks for the review.
>
> I could not reproduce the failure you are seeing; could you perhaps share
> the failing test case?  Here's mine that seems to work as expected:
>
> create table p (a int, b char) partition by list (a);
> create table p1 (a int, b char) partition by list (b);
> alter table p attach partition p1 for values in (1);
>
> -- add a partition to p1
> create table p1a (like p1);
> alter table p1 attach partition p1a for values in ('a');
>
> create table p2 partition of p for values in (1)
>
> \d+ p
> <snip>
> Partition key: LIST (a)
> Partitions: p1 FOR VALUES IN (1),
>             p2 FOR VALUES IN (2)
>
> -- this works (remember that p1 is a partitioned table)
> drop table p1;
> DROP TABLE
>
> \d+ p
> <snip>
> Partition key: LIST (a)
> Partitions: p2 FOR VALUES IN (2)
>
>> Please add a test for that so we can check automatically.
>
> OK, done.

Isn't list_range_parted multilevel partitioned table. It gets dropped
in the testcases. So, I guess, we already have a testcase there.


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