Re: [HACKERS] dropping partitioned tables without CASCADE - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: [HACKERS] dropping partitioned tables without CASCADE
Date
Msg-id CAFjFpRemujuWj07RGHaPkiLNEhC71OBNixbhXLXL0Cqe1bk38g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] dropping partitioned tables without CASCADE  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] PATCH: two slab-like memory allocators
Next
From: Amit Khandekar
Date:
Subject: Re: [HACKERS] UPDATE of partition key