From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | COLUMN MODIFY |
Date: | 2002-12-19 04:54:30 |
Message-ID: | GNELIHDDFBOCMGBFGEFOOELCCEAA.chriskl@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-12-19 05:12:18 | Re: user defined settings (aka user defined guc variables) |
Previous Message | Noel | 2002-12-19 04:51:36 | Re: error when using move, any suggestions? |