COLUMN MODIFY

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

Responses

Browse pgsql-hackers by date

  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?