On Wed, Feb 15, 2017 at 12:08:19PM -0500, 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.
I think we have a precedent for this, and that is the SERIAL data type,
which is really just a macro on top of CREATE SEQUENCE and DEFAULT
nextval() using the sequence. You can manipulate the sequence and the
DEFAULT separately, but if you drop the table the sequence is dropped to
automatically.
This seems like an instructive example of how we have bundled behavior
together in the past in a logical and easy-to-understand way. Of
course, their might be some technical limitations that prevent us from
using this approach, and I would be interested in hearing those details.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +