Re: OID wraparound (was Re: pg_depend)

[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