COLUMN MODIFY - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject COLUMN MODIFY
Date
Msg-id GNELIHDDFBOCMGBFGEFOOELCCEAA.chriskl@familyhealth.com.au
Whole thread Raw
Responses Re: COLUMN MODIFY
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Kevin Brown
Date:
Subject: Re: v7.3.1 tar ready ... please check it ...
Next
From: Tom Lane
Date:
Subject: Re: user defined settings (aka user defined guc variables)