Re: ALTER TABLE DROP COLUMN
От | Bruce Momjian |
---|---|
Тема | Re: ALTER TABLE DROP COLUMN |
Дата | |
Msg-id | 200010092322.TAA24863@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: ALTER TABLE DROP COLUMN (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ALTER TABLE DROP COLUMN
|
Список | 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, Pennsylvania19026
В списке pgsql-hackers по дате отправления: