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. That wouldn't be a problem if we just say to people, if
you want to create a new partition do:
CREATE TABLE new_child ... LIKE child;
then later
ALTER TABLE new_partition ADD INHERITS parent;
> > Basically I think if you're doing multiple inheritance and start using
> > add/drop inherits your column order is going to turn into chop suey quickly.
The column ordering is too important for other purposes. Things like
COPY, INSERT etc all depend upon specific column orderings.
If ADD INHERITS lets a wierd ordering go past that cannot ever be
re-created then everything will start to break.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
