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

[ 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

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

-----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