> -----Original Message-----
> From: Wim.Ceulemans@nice.be [mailto:Wim.Ceulemans@nice.be]
>
> 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?
>
Yes,if dump/restore means restore from pg_dump. pg_dump wouldn't
see the column definition in my implementation.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp