With caveats, it is now possible to drop columns from tables.
The implementation is based on copying the old table to a new one minus
the specified column. This procedure changes the oids of everyone
involved, so I was wondering if
a) this is a good reason to tell people to stop using oids as keys, or
b) if there is some way to keep the oids on both the records and the
pg_class entry.
Is it possible/safe to specify an oid to heap_insert (like tuple->...->oid
= x) if the oid is still in use (in the old table), or would a
heap_delete({from old table}) plus heap_insert({into new table}) work.
Is it possible/safe to change to oid of the new pg_class entry back to the
old one? In that case the trouble of moving over all the constraints, etc.
would be half the work.
Speaking of which, the current implementation loses all constraints,
triggers, rules, comments, etc. (not defaults and notnulls
though). Therefore
1) did I forget anything in the above list
2) how do I find out if the dropped column is referenced in a constraint,
trigger, rule (this is necessary for a correct RESTRICT/CASCADE
implementation)
3) once again, is it possible/safe to do the equivalent of update pg_class
set oid=old where oid=new to save this work?
Oh, btw., heaven help you if you try this on tables that are inherited
from.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
