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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD