Re: [HACKERS] Happy column dropping

[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> 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.

Actually CLUSTER has the same problem, I think.  It may be even worse
because it drops all indexes.  Can you take a look at that code too. 
Some people have reported problems with it, while others are OK.  There
is a cluster TODO mail file in the source tree.  It shows an actual bug
that still exists, plus some other issues with cluster.



Not sure how to deal with this.  I think our whole OID system is messed
up because you can't update the OID column in a table.  That is very
limiting, and some commands like cluster lose oids.  I think we need a
full OID discussion on how to move forward with them.

Why not allow heap_insert to receive the oid as a parameter.  It may
help with cluster too.  Seems like a great idea!

> 
> 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.

I don't know.  I don't see any reason we can't handle that.


--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026