On Thu, 4 Dec 2008, Gregory Stark wrote:
They all seem functional ideas. But it seems to me they're all ideas that would be appropriate if this was a pgfoundry add-on for existing releases.
I was mainly trying to target things that would be achievable within the context of the existing shell script. I think that we need such a script that does 100% of the job and can be tested ASAP. If it's possible to slice the worst of the warts off later, great, but don't drop focus from getting a potential candidate release done first.
How about adding a special syntax for CREATE TABLE which indicates to include a dropped column in that position? Then pg_dump could have a -X option to include those columns as placeholders...This is an internal syntax so I don't see any reason to bother making new keywords just to pretty up the syntax. I don't see a problem with just doing something like "NULL COLUMN (2,1)"
It's a little bit ugly, but given the important of in-place upgrade I would think this is a reasonable hack to consider; two questions:
-Is there anyone whose clean code sensibilities are really opposed to adding such a syntax into the 8.4 codebase?
-If nobody has a beef about it, is this something you could draft a patch for? I'm going to be busy with the upgrade script stuff and don't know much about extending in this area anyway.
Actually removing the attribute is downright hard. You would have to have the table locked, and squeeze the null bitmap -- and if you crash in the middle your data will be toast.
Not being familiar with the code, my assumption was that it would be possible to push all the tuples involved off to another page as if they'd been updated, with WAL logging and everything, similarly to the ideas that keep getting kicked around for creating extra space for header expansion. Almost the same code really, just with the target of moving everything that references the dead column rather than moving just enough to create the space needed. Actually doing the upgrade on the page itself does seem quite perilous.
-- * 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
