Re: ADD/DROP INHERITS

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:

> On Thu, 2006-06-08 at 16:47 -0400, Tom Lane wrote:
> > Greg Stark <gsstark(at)mit(dot)edu> writes:
> > > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

--
greg