On Thu, 2006-06-08 at 17:23 -0400, Greg Stark wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
>
> > On Thu, 2006-06-08 at 16:47 -0400, Tom Lane wrote:
> > > Greg Stark <gsstark@mit.edu> writes:
> > > > Tom Lane <tgl@sss.pgh.pa.us> writes:
> > > >> So? They'll get re-merged with the parent column during CREATE TABLE
> > > >> anyway.
> > >
> > > > But merged columns that are defined locally still appear in the position they
> > > > were defined locally. Not with the other inherited columns.
> >
> > Based on the test case Tom shows, I think we need to enforce that ADD
> > INHERITS will barf if the columns are not in exactly the order they
> > would have been in if we add done a CREATE ... INHERITS followed by a
> > DROP INHERITS.
>
> Well firstly I think that rule is much too hard to explain to users. You would
> have to simplify it into something that makes more sense from a user's point
> of view.
>
> But there's a bigger problem, it won't actually help. To maintain that
> invariant you would never be allowed to DROP a parent unless you had no
> locally defined columns at all. And if you had multiple parents you would have
> further restrictions no multiply defined columns and you can only drop parents
> in the reverse order they were listed on the inherits line.
>
> So basically that rule translates into "you can only add a parent with
> precisely the same definition as your child table and you can only drop a
> parent if it's the last parent in the list and none of the columns are shared
> with other parents". Is that what you want?
Well, what I want and what we can have are frequently separate things.
IMHO the goal here is to be able to decouple/recouple partitions; maybe
others see it differently. If there are restrictions in order to make
that possible, so be it. IMHO the main users of this feature will be
people using single inheritance with all partitions the same and that
situation seems largely unaffected by your unfortunate discoveries.
It seems straightforward to give an example in the manual of the
recommended way to create a table that is destined to become a partition
in the future - whatever that is.
I'd rather have new feature with restrictions, than no new feature.
Somebody for whom the restrictions are a problem may later solve them.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com