RE: [HACKERS] Re: ALTER TABLE DROP COLUMN

Marc G. Fournier <scrappy@hub.org>

From: The Hermit Hacker <scrappy@hub.org>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2000-02-28T03:40:11Z
Lists: pgsql-hackers
On Mon, 28 Feb 2000, Hiroshi Inoue wrote:

> > -----Original Message-----
> > From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> > 
> > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > > Hmm,tuples of multiple version in a table ?
> > > This is neither clean nor easy for me.
> > 
> > I'm worried about it too.  I think it could maybe be made to work,
> > but it seems fragile.
> > 
> > > I may be able to provide another implementation on trial and it
> > > may be easier than only objecting to your proposal.
> > 
> > If you have a better idea, let's hear it!
> >
> 
> I don't want a final implementation this time.
> What I want is to provide a quick hack for both others and me
> to judge whether this direction is good or not.
> 
> My idea is essentially an invisible column implementation.
> DROP COLUMN would change the target pg_attribute tuple
> as follows..
> 	
> 	attnum  ->  an offset - attnum;
> 	atttypid ->  0
> 
> We would be able to see where to change by tracking error/
> crashes caused by this change.
> 
> I would also change attname to '*already dropped %d' for
> examle to avoid duplicate attname. 

Okay, just curious here, but ... what you are proposing *sounds* to me
like half-way to what started this thread. (*Please* correct me if I'm
wrong) ...

Essentially, in your proposal, when you drop a column, all subsequent
tuples inserted/updated would have ... that one column missing?  So,
instead of doing a massive sweep through the table and removing that
column, only do it when an insert/update happens? 

Basically, eliminate the requirement to re-write every tuples, only those
that have activity?