RE: ALTER TABLE DROP COLUMN - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: ALTER TABLE DROP COLUMN
Date
Msg-id EKEJJICOHDIEMGPNIFIJOEEOCHAA.Inoue@tpf.co.jp
Whole thread Raw
In response to Re: ALTER TABLE DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ALTER TABLE DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> -----Original Message-----
> From: Tom Lane
>
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > OK, I am opening this can of worms again.  I personally would like to
> > see this code activated, even if it does take 2x the disk space to alter
> > a column.  Hiroshi had other ideas.  Where did we leave this?  We have
> > one month to decide on a plan.
>
> I think the plan should be to do nothing for 7.1.  ALTER DROP COLUMN
> isn't an especially pressing feature, and so I don't feel that we
> should be hustling to squeeze it in just before beta.  We're already
> overdue for beta.
>

Seems some people expect the implementation in 7.1.
(recent [GENERAL} drop column?)
I could commit my local branch if people don't mind
backward incompatibility.
I've maintained the branch for more than 1 month
and it implements the following TODOs.

* Add ALTER TABLE DROP COLUMN feature
* ALTER TABLE ADD COLUMN to inherited table put column in wrong place
* Prevent column dropping if column is used by foreign key

Comments ?

Hiroshi Inoue

P.S. I've noticed that get_rte_attribute_name() seems to
break my implementation. I'm not sure if I could solve it.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: New unified regression test driver
Next
From: "Frederick W. Reimer"
Date:
Subject: symbol not found in plpgsql.so