Re: ALTER TABLE DROP COLUMN
Bruce Momjian <pgman@candle.pha.pa.us>
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: The Hermit Hacker <scrappy@hub.org>, Hiroshi Inoue <Inoue@tpf.co.jp>, PostgreSQL Development <pgsql-hackers@postgreSQL.org>
Date: 2000-10-09T23:22:13Z
Lists: pgsql-hackers
> The Hermit Hacker <scrappy@hub.org> writes: > > hrmm .. mvcc uses a timestamp, no? is there no way of using that > > timestamp to determine which columns have/haven't been cleaned up > > following a crash? maybe some way of marking a table as being in a 'drop > > column' mode, so that when it gets brought back up again, it is scan'd for > > any tuples older then that date? > > WAL would provide the framework to do something like that, but I still > say it'd be a bad idea. What you're describing is > irrevocable-once-it-starts DROP COLUMN; there is no way to roll it back. > We're trying to get rid of statements that act that way, not add more. > > I am not convinced that a 2x penalty for DROP COLUMN is such a huge > problem that we should give up all the normal safety features of SQL > in order to avoid it. Seems to me that DROP COLUMN is only a big issue > during DB development, when you're usually working with relatively small > amounts of test data anyway. > Bingo! -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026