Re: ADD/DROP INHERITS

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> >> I thought we had agreed that the semantics of ADD INHERITS would be to
> >> reject the command if the child wasn't already suitable to be a child
> >> of the parent.
>
> > I didn't see any discussion like that and I find it pretty surprising.
>
> I'm pretty sure it was mentioned somewhere along the line.
>
> > But that's entirely inconsistent with the way inherited tables work in
> > general.
>
> I don't see any basis for that conclusion. The properties of a table
> are set when it's created and you need to do pretty explicit ALTERs to
> change them.

It just seems weird for:

CREATE TABLE foo (x,y,z) INHERITS (bar)

to not be the equivalent to:

CREATE TABLE foo (x,y,z)
ALTER TABLE foo ADD INHERITS bar

> We do not for example automatically make a unique index for a table when
> someone tries to reference a foreign key to a column set that doesn't
> already have such an index.

But that's not really the same thing. Whether you add the foreign key later or
when you initially create the table it never creates that index.

On the other hand if you add a column to the parent it doesn't complain if not
all the children already have that column -- it goes and adds it recursively.

> In this situation, I think it's entirely reasonable to expect the user
> to do any needed ALTER ADD COLUMN, CONSTRAINT, etc commands before
> trying to attach a child table to a parent. Having the system do it
> for you offers no functionality gain, just a way to shoot yourself in
> the foot.

Well if that's the consensus feeling then it certainly makes my life easier.

--
greg