Re: ALTER TABLE DROP COLUMN
От | Tom Lane |
---|---|
Тема | Re: ALTER TABLE DROP COLUMN |
Дата | |
Msg-id | 7429.971129357@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ALTER TABLE DROP COLUMN (The Hermit Hacker <scrappy@hub.org>) |
Ответы |
Re: ALTER TABLE DROP COLUMN
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. regards, tom lane
В списке pgsql-hackers по дате отправления: