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

On Mon, 24 Jan 2000, Tom Lane wrote:

> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > My idea is as follows.
> 
> > 1)add a visibile/invisible flag to pg_attribute
> > 2)DROP COLUMN marks the column as invisible
> > 3)user interface ignores the columns which are marked invisible
> > 4)heap_formtuple() etc treats the column as NULL internally
> 
> That could be a really good idea.  I don't think you'd even need to
> touch heap_formtuple (and it'd be better not to mess with the guts
> of the system to implement this feature, for both speed and reliability
> reasons).
> 
> Let's see: DROP COLUMN would have to mark the column invisible, remove
> any associated constraints (particularly NOT NULL) and indexes, and
> it'd be done.  The parser would then have to ignore the column when
> doing column name lookups or expansion of '*', and it would have to
> insert a NULL value for the column when transforming INSERT or UPDATE.
> And that'd be just about it.  I like it.
> 
> 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? :(

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