Re: ALTER TABLE DROP COLUMN - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: ALTER TABLE DROP COLUMN |
Date | |
Msg-id | 200006120158.VAA13338@candle.pha.pa.us Whole thread Raw |
In response to | ALTER TABLE DROP COLUMN (Bruce Momjian <pgman@candle.pha.pa.us>) |
Responses |
Re: ALTER TABLE DROP COLUMN
|
List | pgsql-hackers |
> > -----Original Message----- > > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > > > >> 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 > > > > Hmm,I've received no pg-ML mails for more than 1 day. > What's happened with pgsql ML ? Tom says there are tons of messages in the hub.org mail queue, but they are not being delivered. > > > Bruce and I talked about this by phone yesterday, and we realized that > > none of these are very satisfactory. #1 and #2 both have the flaw that > > applications that examine pg_attribute will probably break: they will > > see a sequence of attnum values with gaps in it. And what should the > > rel's relnatts field be set to? #3 and #4 are better on that point, > > but they leave us with the problem of renumbering references to columns > > after the dropped one in constraints, rules, PL functions, etc. > > > > Furthermore, there is a closely related problem that none of these > > approaches give us much help on: recursive ALTER TABLE ADD COLUMN. > > Right now, ADD puts the new column at the end of each table it's added > > to, which often means that it gets a different column number in child > > tables than in parent tables. That leads to havoc for pg_dump. > > > > Inheritance is one of the reason why I didn't take #2. I don't understand > marking is_dropped is needed or not when pg_attribute is overhauled > for inheritance. > I myself have never wanted to use current inheritance functionality > mainly because of this big flaw. Judging from the recent discussion > about oo(though I don't understand details),the change seems to be > needed in order to make inheritance functionality really useful. What would happen is that all the logical attributes would be shifted over, and a new column added using ADD COLUMN would be put in its place. Seems it would work fine. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
pgsql-hackers by date: