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

On Mon, 24 Jan 2000, Tom Lane wrote:

> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org