Re: AW: AW: ALTER TABLE DROP COLUMN

On Fri, 13 Oct 2000, Bruce Momjian wrote:

> [ Charset ISO-8859-1 unsupported, converting... ]
> > > we bite the bullet to the extent of supporting a distinction between
> > > physical and logical column numbers, then ISTM there's no strong need
> > > to do any of this other stuff at all.  I'd expect that an inserted or
> > > updated tuple would have a NULL in any physical column position that
> > > doesn't have an equivalent logical column, so the space cost 
> > > is minimal
> > > (zero, in fact, if there are any other NULLs in the tuple).  Over time
> > > the space occupied by deleted-column data would gradually go away as
> > > tuples got updated.
> > 
> > This said, I think Hiroshi's patch seems a perfect starting point, no ?
> 
> Having phantom columns adds additional complexity to the system overall.
> We have to decide we really want it before making things more complex
> than they already are.

My feel from Tom's email, about changing the "structure" of how a column
is defined, seems to be that he thinks *that* will simplify things, not
make them more complex, but I may be reading things wrong.

Hiroshi's patch would make for a good starting point by bringing in the
ability to do the DROP COLUMN feature, as I understand, without the
rollback capability, with the changes that Tom is proposing bringing it to
a 'rollbackable' stage ...

Again, maybe I am misunderstanding Tom's comments, but the whole column
issue itself sounded like something he wanted to see happen anyway ...