Re: ADD/DROP INHERITS

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ADD/DROP INHERITS
Date: 2006-06-08 21:03:38
Message-ID: 1149800618.9225.21.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-06-08 21:06:55 Re: ADD/DROP constraints
Previous Message Jim C. Nasby 2006-06-08 21:03:12 Re: ADD/DROP INHERITS