> > > 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
