Re: AW: AW: ALTER TABLE DROP COLUMN - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: AW: AW: ALTER TABLE DROP COLUMN
Date
Msg-id 39EAA9EB.A1B2D145@tpf.co.jp
Whole thread Raw
In response to Re: AW: AW: ALTER TABLE DROP COLUMN  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers

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




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Performance on inserts
Next
From: Chris
Date:
Subject: Re: AW: ALTER TABLE DROP COLUMN