On Thu, 4 Dec 2008, Gregory Stark wrote:
Incidentally I got this wrong in my previous email. If we're aiming at 8.4->8.5 as the first in-place update then we actually don't need this in 8.4 at all.
I don't know about everybody else, but I haven't give up on putting together something that works for 8.3. That's why I'm still trying to chase down an approach, even if it's not as elegant as would be possible for 8.4->8.5.
It doesn't sound hard off the top of my head. CREATE TABLE is a bit tricky though, I'll check to make sure it works.
Support for NULL bits in CREATE TABLE might be a helpful trick to have available for this at some point. I'm not sure if it's actually worth doing after the rest of your comments though; see below.
I'm sorry, I think I misunderstood the original idea, what you're talking about makes a lot more sense now. You want to save the space of the dead column by replacing it with NULL, not remove it from the table definition.
Not so much to save the space, it's more about breaking its need for the soon to be removed pg_attribute that used to lead to the dropped column. If you think it's possible to slip that change into the page conversion task, that's probably the ideal way to deal with this.
If 8.4 has the appropriate catalog support to finally execute the full page upgrade vision Zdenek and everybody else has mapped out, it would make me feel better about something that just hacked around this problem crudely for 8.3->8.4. Knowing that a future 8.5 update could finally blow away the bogus dropped columns makes leaving them in there for this round not as bad, and it would avoid needing to mess with the whole pg_dump/CREATE TABLE with NULL bit.
-- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
