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

"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 doUPDATE 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.
        regards, tom lane