Обсуждение: DROP COLUMN status
Can someone comment on where we are with DROP COLUMN? -- 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
> -----Original Message----- > From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On > Behalf Of Bruce Momjian > > Can someone comment on where we are with DROP COLUMN? > I've already committed my trial implementation 3 months ago. They are $ifdef'd by _DROP_COLUMN_HACK__. Please enable the feature and evaluate it. You could enable the feature without initdb. Regards. Hiroshi Inoue Inoue@tpf.co.jp
[ Charset ISO-8859-1 unsupported, converting... ] > > -----Original Message----- > > From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On > > Behalf Of Bruce Momjian > > > > Can someone comment on where we are with DROP COLUMN? > > > > I've already committed my trial implementation 3 months ago. > They are $ifdef'd by _DROP_COLUMN_HACK__. > Please enable the feature and evaluate it. > You could enable the feature without initdb. OK, can you explain how it works, and add any needed documentation so we can enable it. -- 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
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: Thursday, June 08, 2000 1:58 PM > > [ Charset ISO-8859-1 unsupported, converting... ] > > > -----Original Message----- > > > From: pgsql-hackers-owner@hub.org > [mailto:pgsql-hackers-owner@hub.org]On > > > Behalf Of Bruce Momjian > > > > > > Can someone comment on where we are with DROP COLUMN? > > > > > > > I've already committed my trial implementation 3 months ago. > > They are $ifdef'd by _DROP_COLUMN_HACK__. > > Please enable the feature and evaluate it. > > You could enable the feature without initdb. > > OK, can you explain how it works, and add any needed documentation so we > can enable it. > First it's only a trial so I don't implement it completely. Especially I don't completely drop related objects (FK_constraint,triggers,views etc). I don't know whether we could drop them properly or not. The implementation makes the dropped column invisible by changing its attnum to -attnum - offset(currently 20) and attnam to ("*already Dropped%d",attnum). It doesn't touch the table at all. After dropping a column insert/update operation regards the column as NULL and other related stuff simply ignores the column. Regards. Hiroshi Inoue Inoue@tpf.co.jp
Hiroshi Inoue wrote: > > > -----Original Message----- > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Sent: Thursday, June 08, 2000 1:58 PM > > > > [ Charset ISO-8859-1 unsupported, converting... ] > > > > -----Original Message----- > > > > From: pgsql-hackers-owner@hub.org > > [mailto:pgsql-hackers-owner@hub.org]On > > > > Behalf Of Bruce Momjian > > > > > > > > Can someone comment on where we are with DROP COLUMN? > > > > > > > > > > I've already committed my trial implementation 3 months ago. > > > They are $ifdef'd by _DROP_COLUMN_HACK__. > > > Please enable the feature and evaluate it. > > > You could enable the feature without initdb. > > > > OK, can you explain how it works, and add any needed documentation so we > > can enable it. > > > > First it's only a trial so I don't implement it completely. > Especially I don't completely drop related objects > (FK_constraint,triggers,views etc). I don't know whether > we could drop them properly or not. > > The implementation makes the dropped column invisible by > changing its attnum to -attnum - offset(currently 20) and > attnam to ("*already Dropped%d",attnum). It doesn't touch > the table at all. After dropping a column insert/update > operation regards the column as NULL and other related > stuff simply ignores the column. > If one would do a dump/restore of the db after dropping a column, is the column definitely gone then? Regards Wim Ceulemans
> -----Original Message----- > From: Wim.Ceulemans@nice.be [mailto:Wim.Ceulemans@nice.be] > > Hiroshi Inoue wrote: > > > > > -----Original Message----- > > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > > Sent: Thursday, June 08, 2000 1:58 PM > > > > > > [ Charset ISO-8859-1 unsupported, converting... ] > > > > > -----Original Message----- > > > > > From: pgsql-hackers-owner@hub.org > > > [mailto:pgsql-hackers-owner@hub.org]On > > > > > Behalf Of Bruce Momjian > > > > > > > > > > Can someone comment on where we are with DROP COLUMN? > > > > > > > > > > > > > I've already committed my trial implementation 3 months ago. > > > > They are $ifdef'd by _DROP_COLUMN_HACK__. > > > > Please enable the feature and evaluate it. > > > > You could enable the feature without initdb. > > > > > > OK, can you explain how it works, and add any needed > documentation so we > > > can enable it. > > > > > > > First it's only a trial so I don't implement it completely. > > Especially I don't completely drop related objects > > (FK_constraint,triggers,views etc). I don't know whether > > we could drop them properly or not. > > > > The implementation makes the dropped column invisible by > > changing its attnum to -attnum - offset(currently 20) and > > attnam to ("*already Dropped%d",attnum). It doesn't touch > > the table at all. After dropping a column insert/update > > operation regards the column as NULL and other related > > stuff simply ignores the column. > > > > If one would do a dump/restore of the db after dropping a column, is the > column definitely gone then? > Yes,if dump/restore means restore from pg_dump. pg_dump wouldn't see the column definition in my implementation. Regards. Hiroshi Inoue Inoue@tpf.co.jp
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > The implementation makes the dropped column invisible by > changing its attnum to -attnum - offset(currently 20) and > attnam to ("*already Dropped%d",attnum). Ugh. No wonder you had to hack so many places in such an ugly fashion. Why not leave the attnum as-is, and just add a bool saying "column is dropped" to pg_attribute? As long as the parser ignores columns marked that way for field lookup and expansion of *, it seems the rest of the system wouldn't need to treat dropped columns specially in any way. regards, tom lane
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > The implementation makes the dropped column invisible by > > changing its attnum to -attnum - offset(currently 20) and > > attnam to ("*already Dropped%d",attnum). > > Ugh. No wonder you had to hack so many places in such an ugly fashion. > Why not leave the attnum as-is, and just add a bool saying "column is > dropped" to pg_attribute? As long as the parser ignores columns marked > that way for field lookup and expansion of *, it seems the rest of the > system wouldn't need to treat dropped columns specially in any way. If we leave it as positive, don't we have to change user applications that query pg_attribute so they also know to skip it? -- 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
> -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > The implementation makes the dropped column invisible by > > changing its attnum to -attnum - offset(currently 20) and > > attnam to ("*already Dropped%d",attnum). > > Ugh. No wonder you had to hack so many places in such an ugly fashion. > Why not leave the attnum as-is, and just add a bool saying "column is > dropped" to pg_attribute? First,it's only a trial and I haven't gotten any final consensus. It has had the following advantages as a trial. 1) It doesn't require initdb. 2) It makes debugging easier. If I've forgotten to change some places it would cause aborts/asserts in most cases. Now I love my trial implementation more than that of you suggests(it was my original idea) because it's more robust than dropped(invisible) flag implementation. I could hardly expect that no one would ignore the invisible(dropped) flag forever. Anyway I had hidden details behind MACROs mostly so it wouldn't be so difficult to change the implementation as you suggests. Regards. Hiroshi Inoue Inoue@tpf.co.jp
>>>> The implementation makes the dropped column invisible by >>>> changing its attnum to -attnum - offset(currently 20) and >>>> attnam to ("*already Dropped%d",attnum). >> >> Ugh. No wonder you had to hack so many places in such an ugly fashion. >> Why not leave the attnum as-is, and just add a bool saying "column is >> dropped" to pg_attribute? As long as the parser ignores columns marked >> that way for field lookup and expansion of *, it seems the rest of the >> system wouldn't need to treat dropped columns specially in any way. > If we leave it as positive, don't we have to change user applications > that query pg_attribute so they also know to skip it? Good point, but I think user applications that query pg_attribute are likely to have trouble anyway: if they're expecting a consecutive series of attnums then they're going to lose no matter what. regards, tom lane
> -----Original Message----- > From: Hiroshi Inoue > Sent: Friday, June 09, 2000 3:02 AM > > > -----Original Message----- > > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > > > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > > The implementation makes the dropped column invisible by > > > changing its attnum to -attnum - offset(currently 20) and > > > attnam to ("*already Dropped%d",attnum). > > > > Ugh. No wonder you had to hack so many places in such an ugly fashion. > > Why not leave the attnum as-is, and just add a bool saying "column is > > dropped" to pg_attribute? > > Anyway I had hidden details behind MACROs mostly so it > wouldn't be so difficult to change the implementation as > you suggests. > I'm using the following macros(in pg_attribute.h) in my implementation. DROP_COLUMN_INDEX() is used only once except pg_attribute.h. If there are COLUMN_IS_DROPPED() macros,doesn't it mean that they should be changed at any rate ? #ifdef _DROP_COLUMN_HACK__ /** CONSTANT and MACROS for DROP COLUMN implementation*/ #define DROP_COLUMN_OFFSET -20 #define COLUMN_IS_DROPPED(attribute) ((attribute)->attnum <= DROP_COLUMN_OFFS ET) #define DROPPED_COLUMN_INDEX(attidx) (DROP_COLUMN_OFFSET - attidx) #define ATTRIBUTE_DROP_COLUMN(attribute) \ Assert((attribute)->attnum > 0); \ (attribute)->attnum = DROPPED_COLUMN_INDEX((attribute)->attnum);\ (attribute)->atttypid = (Oid) -1; \ (attribute)->attnotnull = false;\ (attribute)->atthasdef = false; #endif /* _DROP_COLUMN_HACK__ */ Regards. Hiroshi Inoue Inoue@tpf.co.jp