Обсуждение: 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