Re: AW: ALTER TABLE DROP COLUMN - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: AW: ALTER TABLE DROP COLUMN
Date
Msg-id Pine.BSF.4.21.0010121501190.4709-100000@thelab.hub.org
Whole thread Raw
In response to Re: AW: ALTER TABLE DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: AW: ALTER TABLE DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 12 Oct 2000, Tom Lane wrote:

> Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:
> > My conclusion would be that we need both:
> > 1. a fast system table only solution with physical/logical column id
> > 2. a tool that does the cleanup (e.g. vacuum) 
> 
> But the peak space usage during cleanup must still be 2X.

Is there no way of doing this such that we have N tuple types in the
table?  So that UPDATE/INSERTs are minus the extra column, while the old
ones just have that column marked as deleted?  Maybe change the stored
value of the deleted field as some internal value that, when vacuum, or
any other operation, sees it, it 'ignores' that field?  maybe something
that when you do an 'alter table drop', it effectively does an UPDATE on
that field to set it to the 'drop column' value?



pgsql-hackers by date:

Previous
From: Dan Moschuk
Date:
Subject: Re: Core dump
Next
From: "David J. MacKenzie"
Date:
Subject: Re: [PATCHES] PostgreSQL virtual hosting support