Обсуждение: AW: AW: ALTER TABLE DROP COLUMN

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

Andreas

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

--  Bruce Momjian                        |  http://candle.pha.pa.us 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
 

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

Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> 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.

I think we do, because it solves more than just the ALTER DROP COLUMN
problem: it cleans up other sore spots too.  Like ALTER TABLE ADD COLUMN
in a table with child tables.

Of course, it depends on just how ugly and intrusive the code changes
are to make physical and logical columns distinct.  I'd like to think
that some fairly limited changes in and around heap_getattr would do
most of the trick.  If we need something as messy as the first-cut
DROP_COLUMN_HACK then I'll look for another way...
        regards, tom lane

Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> 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.
>
> I think we do, because it solves more than just the ALTER DROP COLUMN
> problem: it cleans up other sore spots too.  Like ALTER TABLE ADD COLUMN
> in a table with child tables.
>
> Of course, it depends on just how ugly and intrusive the code changes
> are to make physical and logical columns distinct.  I'd like to think
> that some fairly limited changes in and around heap_getattr would do
> most of the trick.  If we need something as messy as the first-cut
> DROP_COLUMN_HACK then I'll look for another way...
>

Hmm,the implementation using physical and logical attribute numbers
would be much more complicated than first-cut DROP_COLUMN_HACK.
There's no simpler way than first-cut DROP_COLUMN_HACK.
I see no progress in 2x DROP COLUMN implementation.

How about giving up DROP COLUMN forever ?

Regards.

Hiroshi Inoue