ALTER COLUMN/logical column position

Hannu Krosing wrote:

>>To put it differently: a ALTER COLUMN command may never-ever change the 
>>identifier of the column, i.e. attrelid/attnum.
>>    
>>
>
>to be even more restirictive: ALTER COLUMN may never-ever change the
>type of the column, as this too may break some apps. Nah!
>
>  
>
Yeah, and the data should be read only :-)

Seriously: Methinks that only a part of the -patches thread was turned 
over to -hackers, some important parts are missing.

First, there are column type changes that don't need any 
index/view/constraint recheck or data transformation at all, being of 
the very popular class "hell, I need to stuff 12 bytes in my 
varchar(10)". Some months ago, this was discussed, and there was 
consense that binarily compatible types may be changed with few special 
precautions (e.g. varchar(12) -> varchar(10) e.g. needs a check for 
len<=10). As a consequence, this kind of column type change is 
implemented in pgAdmin3".

Probably a large percentage of real life column type changes are such 
binarily compatible ones, so it's senseful to handle them separately.

Second, column type changes needing a nontrivial cast function should be 
implemented in a way that preserve attnum. This could be done like this:
- decompile dependent objects, and memorize them for later recreation
- ADD tmpCol, UPDATE tmpCol=col::newtype, DROP old column, cascading to 
dependent objects, RENAME tmpCol (known stuff)
- restore old attnum, which is a simple UPDATE to pg_attribute at this stage
- recreate all dependent objects

Voila! No need for an additional attpos.

Regards,
Andreas