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?