Peculiarities of using OIDs as primary key

In some older mails in the archive I found rumors of difficulcies that might
occur
when OIDs are used as an integral part of a data model.

I am considering the option of placing an index on the already existing oid
and using
it as the primary key for all tables (saves some space and a sequence
lookup). This
includes saving the oid in foreign keys (virtual ones, not actually declared
references).
I read that using OID in keys is generally a bad idea. Is it really? Why
exactly?

Are there any disadvantages as to reliability or performance apart from
accidentally
forgetting to use the -o option with pg_dump? If so, please give details.

I felt especially worried by a postgres developer's statement in another
archived mail:
"As far as I know, there is no reason oid's have to be unique, especially if
they are in different tables."
(http://archives.postgresql.org/pgsql-hackers/1998-12/msg00570.php)

How unique are oids as of version 7.3 of postgres ?

Is it planned to keep oids semantically the same in future releases of
postgres?
Will the oid type be extended so that oids can be larger than 4 bytes (if
this is
still correct for 7.3) and do not rotate in large systems?


Thanks for your time and advice.

Daniel Alvarez <d-alvarez@gmx.de>

--
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!