Re: [HACKERS] Well, then you keep your darn columns - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Well, then you keep your darn columns
Date
Msg-id 25852.948736429@sss.pgh.pa.us
Whole thread Raw
In response to RE: [HACKERS] Well, then you keep your darn columns  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses Re: [HACKERS] Well, then you keep your darn columns
Re: [HACKERS] Well, then you keep your darn columns
Re: [HACKERS] Well, then you keep your darn columns
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: "Henry B. Hotz"
Date:
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
Next
From: Zeugswetter Andreas SB
Date:
Subject: AW: [HACKERS] Some notes on optimizer cost estimates