Thread: Utility of OIDs in postgres

Hi,

What would be the benefit of creating tables with OIDs as against one's not with OIDs
Giving a unique identifier to each row inserted has some extra efficiency factor involved or what.

Thanks,
Jas

Jasbinder Singh Bali wrote:
> Hi,
>
> What would be the benefit of creating tables with OIDs as against one's not
> with OIDs
> Giving a unique identifier to each row inserted has some extra efficiency
> factor involved or what.

OIDs are used by the various system tables.
Historically, all user tables had them too.
There's no reason to use them in a new system - they offer no advantages
over an ordinary integer primary-key.

--
   Richard Huxton
   Archonet Ltd

Richard Huxton wrote:
> Jasbinder Singh Bali wrote:
>> Hi,
>>
>> What would be the benefit of creating tables with OIDs as against
>> one's not
>> with OIDs
>> Giving a unique identifier to each row inserted has some extra
>> efficiency
>> factor involved or what.
>
> OIDs are used by the various system tables.
> Historically, all user tables had them too.
> There's no reason to use them in a new system - they offer no
> advantages over an ordinary integer primary-key.
>
Generally this is correct. However I can show one case where they are
very useful:

Table 1: oid, id, category, name, desc, f1, f2, f3, f4
Table 2: oid, id, category, name, desc, f1, f2
Table 3: oid, id, category, name, desc, f1, f2, f3, f4, f5, f6, f7, ...

ID is a serial int as primary key.

create view v_demo as
select oid, name, category, desc from table1
union
select oid, name, category, desc from table2
union
select oid, name, category, desc from table3;


As oid is unique across all tables (in fact all database objects), but
serial is unique within a table, there are odd cases like this where
using an oid in each table ensures an automatic unique key in the view.
So oids can be useful.

This is a real case, for listing objects identified in seabed photos,
table1 is substrates, table2 is scampi burrow types, table 3 is taxa.
The user is presented with a pick list on the view, & the oid is used to
specify what has been identified. The underlying tables contain detail
about each category of object. We could do something much more
complicated in an application, but with oids there is no need.

A similar example could be power stations, all have name, output,
contacts, etc, but depending on whether it is coal/gas/hydro/geothermal,
etc, the attributes will vary. So a table for each type, with a view
enabling a common access of the common fields.


Cheers,

   Brent Wood

On May 2, 2007, at 3:58 PM, Brent Wood wrote:

> Richard Huxton wrote:
>>
>>
>> OIDs are used by the various system tables.
>> Historically, all user tables had them too.
>> There's no reason to use them in a new system - they offer no
>> advantages over an ordinary integer primary-key.
>>
> Generally this is correct. However I can show one case where they
> are very useful:
>
> Table 1: oid, id, category, name, desc, f1, f2, f3, f4
> Table 2: oid, id, category, name, desc, f1, f2
> Table 3: oid, id, category, name, desc, f1, f2, f3, f4, f5, f6,
> f7, ...
>
> ID is a serial int as primary key.
>
> create view v_demo as
> select oid, name, category, desc from table1
> union
> select oid, name, category, desc from table2
> union
> select oid, name, category, desc from table3;
>
>
> As oid is unique across all tables (in fact all database objects),
> but serial is unique within a table, there are odd cases like this
> where using an oid in each table ensures an automatic unique key in
> the view. So oids can be useful.

An OID is not guaranteed to be unique. They're only 32 bits wide.
(And if you do wrap them around the failure modes could be far worse
than non-uniqueness in a user table.)

What you want instead is a single sequence that is used to generate
the id field in each table. That guarantees uniqueness, unless you
manage to wrap the sequence around. With a 64 bit id, that's unlikely
to happen.

> This is a real case, for listing objects identified in seabed
> photos, table1 is substrates, table2 is scampi burrow types, table
> 3 is taxa. The user is presented with a pick list on the view, &
> the oid is used to specify what has been identified. The underlying
> tables contain detail about each category of object. We could do
> something much more complicated in an application, but with oids
> there is no need.
>
> A similar example could be power stations, all have name, output,
> contacts, etc, but depending on whether it is coal/gas/hydro/
> geothermal, etc, the attributes will vary. So a table for each
> type, with a view enabling a common access of the common fields.

Cheers,
   Steve

On Thu, May 03, 2007 at 10:58:38AM +1200, Brent Wood wrote:
> As oid is unique across all tables (in fact all database objects), but
> serial is unique within a table, there are odd cases like this where
> using an oid in each table ensures an automatic unique key in the view.
> So oids can be useful.

As pointed out already, this isn't true. However, for the case you
provide you can also use tableoid which uniquely identifies the table.
Thus the combination of a serial primary and table oid is unique across
a single DB.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.