Re: ALTER TABLE DROP COLUMN
От | The Hermit Hacker |
---|---|
Тема | Re: ALTER TABLE DROP COLUMN |
Дата | |
Msg-id | Pine.BSF.4.21.0010092038030.625-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: ALTER TABLE DROP COLUMN (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
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 :)
В списке pgsql-hackers по дате отправления: