On Thu, Feb 16, 2017 at 12:43 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > On 2017/02/16 2:08, Robert Haas wrote: >> On Wed, Feb 15, 2017 at 11:34 AM, Alvaro Herrera >> <alvhe...@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.
Could you possibly post this on a new thread with a reference back to this one? The number of patches on this one is getting a bit hard to track, and some people may be under the misimpression that this one is just about documentation. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
