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