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
