From: Bruce Momjian <bruce@momjian.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Joshua D. Drake <jd@commandprompt.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Corey Huinker <corey.huinker@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Documentation improvements for partitioning
Date: Mon, 20 Feb 2017 15:27:09 -0500
Message-ID: <20170220202709.GA2672@momjian.us> (raw)
In-Reply-To: <CA+TgmoYSuqyDfG2GtU3J=BRUmZHpy7XmcTgBpxw1Vv5a-MmURA@mail.gmail.com>
References: <CA+TgmoaYRbs-m5D-etPa_90Og7NphkvRi9v9dvjHRs-mTCotiA@mail.gmail.com>
<20170215163411.7ozquqahgf64lvui@alvherre.pgsql>
<CA+TgmoYSuqyDfG2GtU3J=BRUmZHpy7XmcTgBpxw1Vv5a-MmURA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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 +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: bruce@momjian.us, robertmhaas@gmail.com, alvherre@2ndquadrant.com, jd@commandprompt.com, simon@2ndquadrant.com, Langote_Amit_f8@lab.ntt.co.jp, corey.huinker@gmail.com
Subject: Re: Documentation improvements for partitioning
In-Reply-To: <20170220202709.GA2672@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox