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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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