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
|
Список | 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 по дате отправления: