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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026