Re: ADD/DROP INHERITS - Mailing list pgsql-hackers

From Zeugswetter Andreas DCP SD
Subject Re: ADD/DROP INHERITS
Date
Msg-id E1539E0ED7043848906A8FF995BDA5790116B707@m0143.s-mxs.net
Whole thread Raw
In response to ADD/DROP INHERITS  (Greg Stark <gsstark@mit.edu>)
Responses Re: ADD/DROP INHERITS  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
> > > 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

Imho the op should only choose that path if he wants to fill the table
before
adding the inheritance. It makes no sense to add columns with default
values
to existing rows of the child table, especially when you inherit the
defaults
from the parent.

So I agree with Tom, that ADD INHERITS should not add columns.

Andreas


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: That EXPLAIN ANALYZE patch still needs work
Next
From: Teodor Sigaev
Date:
Subject: Re: Connection Broken with Custom Dicts for TSearch2