Re: pg_migrator versus inherited columns

On Wed, Jul 1, 2009 at 11:36 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> (It's a good thing we added ADD INHERIT in 8.4, or we'd be completely
> up the creek here.)  In this way we can ensure that the physical order
> of columns really is what it needs to be in the child table.  Dropped
> columns can then be managed in the same way as the current code does,
> but it'll actually work.  (We have to drop them before doing the
> ADD INHERIT of course.)
>
> Comments?

Uhm, we've had ADD INHERIT since 8.2 -- that was my first patch.

This will result in all the columns being marked attislocal. Ie, if
they're dropped from the parent they won't be dropped automatically
from the children any longer.

Frankly I never really liked attislocal -- it seems to me the user
knows when he's dropping the column whether he wants it dropped from
the children and should be able to explicitly request it to cascade or
not. I can't imagine many use cases where you want it to cascade to
some children but not others based on how they were originally
created.

--
greg
http://mit.edu/~gsstark/resume.pdf