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

From Hiroshi Inoue
Subject RE: ALTER TABLE DROP COLUMN
Date
Msg-id EKEJJICOHDIEMGPNIFIJEELACBAA.Inoue@tpf.co.jp
Whole thread Raw
In response to Re: ALTER TABLE DROP COLUMN  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses RE: ALTER TABLE DROP COLUMN
Re: ALTER TABLE DROP COLUMN
Re: ALTER TABLE DROP COLUMN
List pgsql-hackers
> -----Original Message-----
> From: pgsql-hackers-owner@hub.org 
> [mailto:pgsql-hackers-owner@hub.org]On Behalf Of Bruce Momjian
> 
> Seems we have 4 DROP COLUMN ideas:
> 
>     Method                                                  Advantage
>     -----------------------------------------------------------------
> 1    invisible column marked by negative attnum        fast
> 2    invisible column marked by is_dropped column        fast
> 3    make copy of table without column            col removed
> 4    make new tuples in existing table without column    col removed
> 
> Folks, we had better choose one and get started.  
> 
> Number 1 Hiroshi has ifdef'ed out in the code.  Items 1 and 2 have
> problems with backend code and 3rd party code not seeing the dropped
> columns,

Hmm,doesn't  *not seeing*  mean the column is dropped ?

> or having gaps in the attno numbering. Number 3 has problems
> with making it an atomic operation, and number 4 is described below. 
>

Don't forget another important point.

Currently even DROP TABLE doesn't remove related objects completely.
And I don't think I could remove objects related to the dropping column
completely using 1)2) in ALTER TABLE DROP COLUMN implementation.

Using 3)4) we should not only remove objects as 1)2) but also
change attnum-s in all objects related to the relation. Otherwise
PostgreSQL would do the wrong thing silently.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: Update doc changes needed
Next
From: Andrew McMillan
Date:
Subject: Re: Re: Big replication project, please help