Re: [HACKERS] Documentation improvements for partitioning
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] Documentation improvements for partitioning |
Дата | |
Msg-id | ca132b99-0d18-439a-fe65-024085449259@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Documentation improvements for partitioning (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Documentation improvements for partitioning
Re: [HACKERS] Documentation improvements for partitioning |
Список | pgsql-hackers |
On 2017/02/16 2:08, Robert Haas wrote: > On Wed, Feb 15, 2017 at 11:34 AM, Alvaro Herrera > <alvherre@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: