On Wednesday 26 Feb 2003 1:04 pm, daniel alvarez wrote:
> In some older mails in the archive I found rumors about 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?
OIDs are not even guaranteed to be there any more - you can create a table
WITHOUT OIDs if you want to save some space. If you want a numeric primary
key, I'd recommend int4/int8 attached to a sequence - it's much clearer
what's going on then.
> 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 ?
OIDs are unique per object (table) I believe, no more so. See chapter 5.10 of
the user guide for details. They are used to identify system objects and so
the fact that a function and a table could both have the same OID should
cause no problems.
> Is it planned to keep oids semantically the same in future releases of
> postgres?
Couldn't say - don't see why not.
> 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?
Strikes me as unlikely, though I'm not a developer. Look into 8-byte
serial/sequences.
--
Richard Huxton