RE: [HACKERS] Re: ALTER TABLE DROP COLUMN - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: [HACKERS] Re: ALTER TABLE DROP COLUMN
Date
Msg-id 000801bf819a$eb8b8800$2801007e@tpf.co.jp
Whole thread Raw
In response to Re: [HACKERS] Re: ALTER TABLE DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses RE: [HACKERS] Re: ALTER TABLE DROP COLUMN  (The Hermit Hacker <scrappy@hub.org>)
RE: [HACKERS] Re: ALTER TABLE DROP COLUMN  (Don Baccus <dhogaza@pacifier.com>)
List pgsql-hackers
> -----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. 
Regards.

Hiroshi Inoue
Inoue@tpf.co.jp 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN
Next
From: The Hermit Hacker
Date:
Subject: RE: [HACKERS] Re: ALTER TABLE DROP COLUMN