Did I miss a discussion here on implementing this, and how? Sounds to me
like a week and a bit before planned beta, an *incomplete* feature has
been shoved into the source tree with zero forewarning or discussion ...
Okay, my turn here ... I vote for this to be *reverted*!!
On Sun, 23 Jan 2000, Peter Eisentraut wrote:
> 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
>
>
>
>
> ************
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org