[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