Re: ALTER TABLE DROP COLUMN

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ALTER TABLE DROP COLUMN
Дата
Msg-id 6203.960614077@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: ALTER TABLE DROP COLUMN  (Don Baccus <dhogaza@pacifier.com>)
Ответы Re: ALTER TABLE DROP COLUMN  (Don Baccus <dhogaza@pacifier.com>)
Список pgsql-hackers
Don Baccus <dhogaza@pacifier.com> writes:
> Oracle gives you the choice between the "cheating" fast method(s) and
> the "real" slow (really slow?) real method.

> So there's at least real world experience by virtue of example by
> the world's most successful database supplier that user control
> over "hide the column" and "really delete the column" is valuable.

Sure, but you don't need any help from the database to do "really delete
the column".  SELECT INTO... is enough, and it's not even any slower
than the implementations under discussion.

So I'm satisfied if we offer the "hide the column" approach.

Has anyone thought about what happens to table constraints that use the
doomed column?  Triggers, RI rules, yadda yadda?

Has anyone thought about undoing a DELETE COLUMN?  The data is still
there, at least in tuples that have not been updated, so it's not
totally unreasonable.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: ALTER TABLE DROP COLUMN
Следующее
От: Don Baccus
Дата:
Сообщение: Re: ALTER TABLE DROP COLUMN