On Wed, Jul 1, 2009 at 11:36 PM, Tom Lane<t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
