In some older mails in the archive I found rumors about difficulcies that
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
it as the primary key for all tables (saves some space and a sequence
includes saving the oid in foreign keys (virtual ones, not actually declared
I read that using OID in keys is generally a bad idea. Is it really? Why
Are there any disadvantages as to reliability or performance apart from
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
"As far as I know, there is no reason oid's have to be unique, especially if
they are in different tables."
How unique are oids as of version 7.3 of postgres ?
Is it planned to keep oids semantically the same in future releases of
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(at)gmx(dot)de>
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
pgsql-performance by date
|Next:||From: Richard Huxton||Date: 2003-02-26 13:58:53|
|Subject: Re: OIDs as keys|
|Previous:||From: Andrew Sullivan||Date: 2003-02-26 12:00:40|
|Subject: Re: Index File growing big.|