Re: ALTER TABLE DROP COLUMN
От | Bruce Momjian |
---|---|
Тема | Re: ALTER TABLE DROP COLUMN |
Дата | |
Msg-id | 200010092346.TAA27753@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: ALTER TABLE DROP COLUMN (The Hermit Hacker <scrappy@hub.org>) |
Ответы |
Re: ALTER TABLE DROP COLUMN
|
Список | pgsql-hackers |
> On Mon, 9 Oct 2000, Bruce Momjian wrote: > > > > 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! > > you are jumping on your 'I agree/Bingo' much much too fast :) You know this DROP COLUMN is a hot button for me. -- 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 по дате отправления: