Skip site navigation (1) Skip section navigation (2)

RE: [HACKERS] Re: ALTER TABLE DROP COLUMN

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL Development" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: RE: [HACKERS] Re: ALTER TABLE DROP COLUMN
Date: 2000-02-28 03:21:36
Message-ID: 000801bf819a$eb8b8800$2801007e@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> 
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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(at)tpf(dot)co(dot)jp 

In response to

Responses

pgsql-hackers by date

Next:From: The Hermit HackerDate: 2000-02-28 03:40:11
Subject: RE: [HACKERS] Re: ALTER TABLE DROP COLUMN
Previous:From: Bruce MomjianDate: 2000-02-28 02:34:55
Subject: Re: [HACKERS] Re: ALTER TABLE DROP COLUMN

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group