Re: ADD/DROP INHERITS

Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.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.  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.

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.
        regards, tom lane