Hiroshi Inoue wrote:
>
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> > Sent: Thursday, June 08, 2000 1:58 PM
> >
> > [ Charset ISO-8859-1 unsupported, converting... ]
> > > > -----Original Message-----
> > > > From: pgsql-hackers-owner@hub.org
> > [mailto:pgsql-hackers-owner@hub.org]On
> > > > Behalf Of Bruce Momjian
> > > >
> > > > Can someone comment on where we are with DROP COLUMN?
> > > >
> > >
> > > I've already committed my trial implementation 3 months ago.
> > > They are $ifdef'd by _DROP_COLUMN_HACK__.
> > > Please enable the feature and evaluate it.
> > > You could enable the feature without initdb.
> >
> > OK, can you explain how it works, and add any needed documentation so we
> > can enable it.
> >
>
> First it's only a trial so I don't implement it completely.
> Especially I don't completely drop related objects
> (FK_constraint,triggers,views etc). I don't know whether
> we could drop them properly or not.
>
> The implementation makes the dropped column invisible by
> changing its attnum to -attnum - offset(currently 20) and
> attnam to ("*already Dropped%d",attnum). It doesn't touch
> the table at all. After dropping a column insert/update
> operation regards the column as NULL and other related
> stuff simply ignores the column.
>
If one would do a dump/restore of the db after dropping a column, is the
column definitely gone then?
Regards
Wim Ceulemans