| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Don Baccus <dhogaza(at)pacifier(dot)com> |
| Cc: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "PostgreSQL Development" <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: ALTER TABLE DROP COLUMN |
| Date: | 2000-06-10 05:14:37 |
| Message-ID: | 6203.960614077@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Don Baccus <dhogaza(at)pacifier(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Don Baccus | 2000-06-10 12:43:06 | Re: ALTER TABLE DROP COLUMN |
| Previous Message | Don Baccus | 2000-06-10 04:57:58 | RE: ALTER TABLE DROP COLUMN |