From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: dropping partitioned tables without CASCADE |
Date: | 2017-02-22 01:49:45 |
Message-ID: | 98a8c721-981b-8156-5581-91f97ab59cb1@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017/02/21 20:17, Ashutosh Bapat wrote:
> On Tue, Feb 21, 2017 at 12:05 PM, Amit Langote wrote:
>> On 2017/02/20 21:49, Ashutosh Bapat wrote:
>>> Here are some comments
>>>
>>> For the sake of readability you may want reverse the if and else order.
>>> - recordDependencyOn(&childobject, &parentobject, DEPENDENCY_NORMAL);
>>> + if (!child_is_partition)
>>> + recordDependencyOn(&childobject, &parentobject, DEPENDENCY_NORMAL);
>>> + else
>>> + recordDependencyOn(&childobject, &parentobject, DEPENDENCY_AUTO);
>>> like
>>> + if (child_is_partition)
>>> + recordDependencyOn(&childobject, &parentobject, DEPENDENCY_AUTO);
>>> + else
>>> + recordDependencyOn(&childobject, &parentobject, DEPENDENCY_NORMAL);
>>
>> Sure, done.
>
> I still see
> - recordDependencyOn(&childobject, &parentobject, DEPENDENCY_NORMAL);
> + if (!child_is_partition)
> + recordDependencyOn(&childobject, &parentobject, DEPENDENCY_NORMAL);
> + else
> + recordDependencyOn(&childobject, &parentobject, DEPENDENCY_AUTO);
>
> Are you sure you have attached the right patch?
Oops, really fixed this time.
>>> --- cleanup: avoid using CASCADE
>>> -DROP TABLE list_parted, part_1;
>>> -DROP TABLE list_parted2, part_2, part_5, part_5_a;
>>> -DROP TABLE range_parted, part1, part2;
>>> +-- cleanup
>>> +DROP TABLE list_parted, list_parted2, range_parted;
>>> Testcases usually drop one table at a time, I guess, to reduce the differences
>>> when we add or remove tables from testcases. All such blocks should probably
>>> follow same policy.
>>
>> Hmm, I see this in src/test/regress/sql/inherit.sql:141
>>
>> DROP TABLE firstparent, secondparent, jointchild, thirdparent, otherchild;
>
> Hmm, I can spot some more such usages. Let's keep this for the
> committer to decide.
Sure.
>>> BTW, I noticed that although we are allowing foreign tables to be
>>> partitions, there are no tests in foreign_data.sql for testing it. If
>>> there would have been we would tests DROP TABLE on a partitioned table
>>> with foreign partitions as well. That file has testcases for testing
>>> foreign table inheritance, and should have tests for foreign table
>>> partitions.
>>
>> That makes sense. Patch 0002 is for that (I'm afraid this should be
>> posted separately though). I didn't add/repeat all the tests that were
>> added by the foreign table inheritance patch again for foreign partitions
>> (common inheritance rules apply to both cases), only added those for the
>> new partitioning commands and certain new rules.
>
> Thanks. Yes, a separate thread would do. I will review it there. May
> be you want to add it to the commitfest too.
Posted in a new thread titled "foreign partition DDL regression tests".
Thanks,
Amit
Attachment | Content-Type | Size |
---|---|---|
0001-Allow-dropping-partitioned-table-without-CASCADE.patch | text/x-diff | 12.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-02-22 01:56:54 | Re: dropping partitioned tables without CASCADE |
Previous Message | Amit Langote | 2017-02-22 01:40:07 | foreign partition DDL regression tests |