Re: [HACKERS] Well, then you keep your darn columns

On Mon, 24 Jan 2000, Bruce Momjian wrote:

> > > The only drawback of this scheme is that the space occupied by the
> > > deleted column wouldn't go away immediately (in any given tuple,
> > > it'd be reclaimed on the next UPDATE of the tuple).  On the other hand,
> > > you could construe that as a feature --- you don't have to wait around
> > > for a DROP COLUMN to finish.  Anyone who did want to reclaim space
> > > immediately could do
> > >     UPDATE table SET someothercolumn = someothercolumn;
> > > followed by a VACUUM.  But I bet a lot of people would be just as
> > > happy to let it happen in background.
> > 
> > Hey Bruce ... Look here ^^^^ :)
> > 
> > Oh, there is a second drawback to it though ...
> > 
> > DROP COLUMN name
> > ADD COLUMN name <of a different type>
> > 
> > Then what? :(
> 
> Double-yikes.  There goes that idea, or does it?  Attributes are

not necessarily, just playing devil's advocate ... :)


> numbered.  How does a missing attribute get handled for new rows?
> My guess is that we have to keep this thing around forever.  Can you
> imagine having all those user apps tha query pg_attribute supress that
> column.  Sound like too much work to me.

I *still* think the best is the "re-write the table in place" method
... we already have most of the logic, I would think, from VACUUM ...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org