ALTER TABLE MODIFY COLUMN
От | Mark Butler |
---|---|
Тема | ALTER TABLE MODIFY COLUMN |
Дата | |
Msg-id | 3AD66909.F391BD34@middle.net обсуждение исходный текст |
Ответы |
Re: ALTER TABLE MODIFY COLUMN
|
Список | pgsql-hackers |
I was looking at how hard it would be to support altering column types and it seems to me that it would be trivial to support changing nullability, increasing the maximum length of the VARCHAR data type and increasing the precision or scale of the DECIMAL / NUMERIC data type. Oracle allows you to update a column to null and then modify its data type to any other type. This is easy because it stores all columns in a variable length format and a null looks the same regardless of type. I understand that with the current heap tuple format described in backend/access/common.c that changing the type of any fixed length attribute requires updating every row. Surely if we have an write exclusive table lock we can rewrite tuples in place rather than creating new versions with its corresponding 2x space requirement. We could presumably do the following to change a column data type: Preconditions: 1. Type conversion is possible from old type to new type and either a) old type is unconditionally convertible(e.g. length/precision increasing) b) read locked scan of table reveals that all values are convertible2. Exclusive write lock on table if(new and old types are variable length and are binary compatible){ 1. Change type in catalog 2. Done} else{ 1. Visit all current tuples and rewrite in place, converting attribute value to new type, and shifting all other attributes and null bitmask appropriately 2. Change type in catalog 3. Done} Does this sound reasonable? Also, is anyone working on ALTER TABLE DROP COLUMN right now? Speaking of which, couldn't we make it so that UPDATES and DELETES running under an exclusive table lock do an inline vacuum? - Mark Butler
В списке pgsql-hackers по дате отправления: