> -----Original Message-----
> From: Don Baccus [mailto:dhogaza@pacifier.com]
>
> At 04:23 PM 10/12/00 +0200, Zeugswetter Andreas SB wrote:
>
> >My conclusion would be that we need both:
> >1. a fast system table only solution with physical/logical column id
> >2. a tool that does the cleanup (e.g. vacuum)
>
> Oracle provides both styles of "drop column" - the "hide the column's
> data and make it logically disappear" style, and the "grind through
> and delete all the data as well as make the column disappear from
> view". So there's evidence of a need for both styles.
>
> If you choose the "hide the data" style, I don't know if you can later
> recover that space.
>
> However, despite the above I think a 2x "grind through and remove the
> data" DROP COLUMN would be a welcome first addition, and would meet the
> needs of a very high percentage of the current user base.
This style of "DROP COLUMN" would change the attribute
numbers whose positons are after the dropped column.
Unfortunately we have no mechanism to invalidate/remove
objects(or prepared plans) which uses such attribute numbers.
And I've seen no proposal/discussion to solve this problem
for DROP COLUMN feature. We wound't be able to prevent
PostgreSQL from doing the wrong thing silently.
When I used Oracle,I saw neither option of DROP COLUMN
feature. It seems to tell us that the implementation isn't
that easy. It may not be a bad choise to give up DROP
COLUMN feature forever.
> A future
> option to just hide the data would most likely be welcome, too.
>
My trial implementation using physical/logical attribute numbers
isn't so clean as I expected. I'm inclined to restrict my change to
fix the TODO
* ALTER TABLE ADD COLUMN to inherited table put column in wrong place
though it would also introduce a backward compatibility.
I could live without DROP COLUMN feature though I couldn't
live without ADD COLUMN feature.
Comments ?
Regards.
Hiroshi Inoue
