From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Documentation improvements for partitioning |
Date: | 2017-02-16 07:13:01 |
Message-ID: | ca132b99-0d18-439a-fe65-024085449259@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017/02/16 2:08, Robert Haas wrote:
> On Wed, Feb 15, 2017 at 11:34 AM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
>> I think new-style partitioning is supposed to consider each partition as
>> an implementation detail of the table; the fact that you can manipulate
>> partitions separately does not really mean that they are their own
>> independent object. You don't stop to think "do I really want to drop
>> the TOAST table attached to this main table?" and attach a CASCADE
>> clause if so. You just drop the main table, and the toast one is
>> dropped automatically. I think new-style partitions should behave
>> equivalently.
>
> That's a reasonable point of view. I'd like to get some more opinions
> on this topic. I'm happy to have us do whatever most people want, but
> I'm worried that having table inheritance and table partitioning work
> differently will be create confusion. I'm also suspicious that there
> may be some implementation difficulties. On the hand, it does seem a
> little silly to say that DROP TABLE partitioned_table should always
> fail except in the degenerate case where there are no partitions, so
> maybe changing it is for the best.
So I count more than a few votes saying that we should be able to DROP
partitioned tables without specifying CASCADE.
I tried to implement that using the attached patch by having
StoreCatalogInheritance1() create DEPENDENCY_AUTO dependency between
parent and child if the child is a partition, instead of DEPENDENCY_NORMAL
that would otherwise be created. Now it seems that that is one way of
making sure that partitions are dropped when the root partitioned table is
dropped, not sure if the best; why create the pg_depend entries at all one
might ask. I chose it for now because that's the one with fewest lines of
change. Adjusted regression tests as well, since we recently tweaked
tests [1] to work around the irregularities of test output when using CASCADE.
Thanks,
Amit
[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c397814
Attachment | Content-Type | Size |
---|---|---|
0001-Allow-dropping-partitioned-table-without-CASCADE.patch | text/x-diff | 11.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-02-16 07:27:39 | Re: UPDATE of partition key |
Previous Message | Amit Khandekar | 2017-02-16 06:50:54 | Re: UPDATE of partition key |