From: | daniel alvarez <d-alvarez(at)gmx(dot)de> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Peculiarities of using OIDs as primary key |
Date: | 2003-02-25 20:46:47 |
Message-ID: | 19440.1046206007@www26.gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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(at)gmx(dot)de>
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!
From | Date | Subject | |
---|---|---|---|
Next Message | Eric B.Ridge | 2003-02-25 21:15:09 | Re: triggers |
Previous Message | Justin Clift | 2003-02-25 20:27:15 | Re: error compiling 7.3.2 on solaris 8- library conflict |