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

From Zeugswetter Andreas SB
Subject AW: AW: ALTER TABLE DROP COLUMN
Date
Msg-id 11C1E6749A55D411A9670001FA6879633680A3@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
Responses Re: AW: AW: ALTER TABLE DROP COLUMN  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
> 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


pgsql-hackers by date:

Previous
From: Zeugswetter Andreas SB
Date:
Subject: AW: Inserting a select statement result into another ta ble
Next
From: Bruce Momjian
Date:
Subject: Re: AW: AW: ALTER TABLE DROP COLUMN