Sorry to be commenting so late.
We could do that CLUSTER way of making a new heap file, but we rejected
that for DROP COLUMN, so I am not sure why we would use that for ALTER
COLUMN. Can anyone think of a good reason?
Clearly if the new data type is binary compatible and it is just a
catalog change, we can do that in place.
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
> Hey guys,
>
> I was just thinking about altering column type. Now, I'm not actually going
> to implement it any time soon, but I'm just thinking about it!!!
>
> One proposal was to introduce a new pg_attribute column called 'attlognum'
> so changing a column would involve adding a new column, dropping the old one
> and nudging the attlognum so that the columns are still select *'d in the
> same order.
>
> That involves catalog changes, etc.
>
> My idea is why not do what cluster does? Can we just simply write an entire
> new relation with the new type, update relfilenode and drop the old
> relation?
>
> ISTM that that would prevent catalog changes and would occupy identical disk
> space (2 x table size) during the ALTER, but would automatically 'free'
> itself back down to 1 x table size. Otherwise, the user has to do a vacuum
> full.
>
> Actually, if the type is binary compatible with the old type, all you need
> to update is the catalog.
>
> The existing DROP COLUMN implementation could even be changed to work like
> that, so long as we just leave the attisdropped column always false.
>
> What do you think?
>
> Chris
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
