Re: alter table drop column status - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: alter table drop column status
Date
Msg-id EKEJJICOHDIEMGPNIFIJMEEHGMAA.Inoue@tpf.co.jp
Whole thread Raw
In response to Re: alter table drop column status  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: alter table drop column status  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-hackers
> -----Original Message-----
> From: Tom Lane
>
> Kovacs Zoltan <kovacsz@pc10.radnoti-szeged.sulinet.hu> writes:
> > Browsing the archives, I found the latest comment about dropping columns
> > about summer 2000 closing with Hiroshi's unapplied (?) hack. What is the
> > current status of the implementation?
>
> It was applied,

No there was an unapplied hack which uses logical/physical
attribute numbers. I have synchronized it with cvs for a
year or so but stop it now. Though it had some flaws It
solved 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

I gave up to apply the hack mainly because it may introduce
the maintenance headache.

> and it's in there with #ifdef _DROP_COLUMN_HACK__,
> but I believe Hiroshi has given up on that approach as unworkable.
>
> The #ifdef'd code is still there (in most places anyway) because no
> one has bothered to rip it out.  But I doubt it would work very well
> if enabled --- the code mods in the last year or so have not taken
> any notice of _DROP_COLUMN_HACK__.

The code doesn't work since long. I would remove it after 7.3 tree
is branched.

regards,
Hiroshi Inoue



pgsql-hackers by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: again on index usage (7.1.3)
Next
From: Brent Verner
Date:
Subject: Re: [GENERAL] Feature enhancement request : use of libgda in