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, Pennsylvania 19026

Wed, 7 Jun 2000 23:09:07 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
DROP COLUMN status
> -----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
 

Thu, 8 Jun 2000 13:07:44 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: DROP COLUMN status
[ 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, Pennsylvania 19026

Thu, 8 Jun 2000 00:57:35 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: DROP COLUMN status
> -----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

Thu, 8 Jun 2000 15:05:24 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: DROP COLUMN status
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

Thu, 08 Jun 2000 09:16:08 +0200
Wim Ceulemans <wim.ceulemans@nice.be>
Re: DROP COLUMN status
> -----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

Thu, 8 Jun 2000 16:28:56 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: DROP COLUMN status
"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

Thu, 08 Jun 2000 10:20:11 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: DROP COLUMN status 
> "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, Pennsylvania 19026

Thu, 8 Jun 2000 11:41:43 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: DROP COLUMN status
> -----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

Fri, 9 Jun 2000 03:01:43 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: DROP COLUMN status 
>>>> 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

Thu, 08 Jun 2000 15:52:43 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: DROP COLUMN status 
> -----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


Fri, 9 Jun 2000 09:10:57 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: DROP COLUMN status 