Christopher Kings-Lynne wrote: > > Hmmm. Personally, I think that a DROP COLUMN that cannot reclaim space is > kinda useless - you may as well just use a view!!! > > So how would this occur?: > > 1. Lock target table for writing (allow reads) > 2. Begin a table scan on target table, writing > a new file with a particular filenode > 3. Delete the attribute row from pg_attribute > 4. Point the table in the catalog to the new filenode > 5. Release locks > 6. Commit transaction > 7. Delete orhpan filenode > > i. Upon postmaster startup, remove any orphaned filenodes > > The real problem here is the fact that there are now missing attnos in > pg_attribute. Either that's handled or we renumber the attnos - which is > also quite hard?
The attnos should be renumbered and it's easy. But the above seems only 20% of the total implementation. If the attnos are renumbered, all objects which refer to the numbers must be invalidated or re-compiled ... For example the parameters of foreign key constraints triggers are consist of relname and colnames currently. There has been a proposal that change to use relid or column numbers instead. Certainly it makes RENAME happy but DROP COLUMN unhappy. If there's a foreign key a_rel/1/3 and the second column of the relation is dropped the parameter must be changed to be a_rel/1/2. If neither foreign key stuff nor DROP COLUMN take the other into account, the consistency is easily broken. regards, Hiroshi Inoue ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
