Re: OID wraparound (was Re: pg_depend) - Mailing list pgsql-hackers

[trimmed cc:list]
On Wednesday 18 July 2001 17:09, Bruce Momjian wrote:
> OK, we need to vote on whether Oid's are optional, and whether we can
> have them not created by default.

[All the below IMHO]

OID's should be optional.

System tables that absolutely have to have OIDs may keep them.

No new OID usage, period.  Use some other unique primary key.

Default user tables to no OIDs.  

Document other means by which rows that are otherwise identical can be made 
unique, for the purpose of expunging duplicates (ctids or whatever is 
appropriate).

Allow a SET DEFAULT CREATE OIDS style option for those who just _must_ have 
OIDS -- and integrate with GUC.  Document that OID wrap can occur, and that 
it can cause Bad Things to happen.

Allow a CREATE TABLE WITH OIDS to supplement the above option setting.

Now for a question:  OID creation seems to be a low-overhead task. Is the 
creation of SERIAL PRIMARY KEY values as efficient?  Or will we be shooting 
ourselves in the performance foot if frequently-accessed system tables go 
from OID usage to SERIAL PRIMARY KEY usage?

> I meant we use them in many cases to link entries, and in pg_description
> for descriptions and lots of other things that may use them in the
> future for system table use.

If I may be so bold: we discourage users from using OIDs as a SERIAL PRIMARY 
KEY, yet the system does it en masse.

I say all that knowing full well that I am using OIDs in my own 
applications.... :-) I guess I'll just need to switch to proper SERIALs and 
PRIMARY KEYs.  Of course, if I wanted to be stubborn, I'd just use the GUC 
option to enable OIDs system-wide by default....

However, the utility of INSERT returning a unique identifier to the inserted 
row needs to be addressed -- I would prefer it return the defined PRIMARY KEY 
value for the tuple just inserted, if a PRIMARY KEY is defined.  If no 
PRIMARY KEY is defined, return a unique identifier (even a temporary one like 
the ctid) so that I have that information for use later in the application. 
The utility of that feature should not be underestimated.

Such a return value would of course have to be returned as a tuple with all 
the necessary metadata to process the return value -- this is probably not a 
trivial change.

Of course, I may be missing some essential usage of OID's.... and I reserve 
the right to be wrong.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11