Re: ADD/DROP INHERITS

From: "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at>
To: "Greg Stark" <gsstark(at)mit(dot)edu>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ADD/DROP INHERITS
Date: 2006-06-08 08:43:46
Message-ID: E1539E0ED7043848906A8FF995BDA5790116B707@m0143.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2006-06-08 10:42:18 Re: Connection Broken with Custom Dicts for TSearch2
Previous Message Simon Riggs 2006-06-08 08:17:00 Re: That EXPLAIN ANALYZE patch still needs work