Happy column dropping
От | Peter Eisentraut |
---|---|
Тема | Happy column dropping |
Дата | |
Msg-id | Pine.LNX.4.21.0001221454130.3007-100000@localhost.localdomain обсуждение исходный текст |
Ответы |
Re: [HACKERS] Happy column dropping
Re: [HACKERS] Happy column dropping Re: [HACKERS] Happy column dropping |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: