Skip site navigation (1) Skip section navigation (2)

Re: pg_migrator versus inherited columns

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_migrator versus inherited columns
Date: 2009-07-02 00:17:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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


In response to


pgsql-hackers by date

Next:From: Josh BerkusDate: 2009-07-02 00:21:33
Subject: First CommitFest: July 15th
Previous:From: KaiGai KoheiDate: 2009-07-01 23:59:58
Subject: Re: [PATCH] [v8.5] Security checks on largeobjects

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group