Re: ALTER TABLE DROP COLUMN - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ALTER TABLE DROP COLUMN
Date
Msg-id 6203.960614077@sss.pgh.pa.us
Whole thread Raw
In response to RE: ALTER TABLE DROP COLUMN  (Don Baccus <dhogaza@pacifier.com>)
Responses Re: ALTER TABLE DROP COLUMN  (Don Baccus <dhogaza@pacifier.com>)
List 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 by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: ALTER TABLE DROP COLUMN
Next
From: Don Baccus
Date:
Subject: Re: ALTER TABLE DROP COLUMN