Re: OID wraparound (was Re: pg_depend)

Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> What about pg_log? It will easily become a huge file. Currently the
> only solution is re-installing whole database, that is apparently
> unacceptable for very big installation like 1TB.

That's part of the XID wraparound issue, which is a separate
discussion... but yes, I want to do something about that for 7.2 also.

> So are we going to remove OID?

No, only make it optional for user tables.

> I see following in the SQL99 draft (not
> sure it actually becomes a part of the SQL99 standard, though). Can we
> implement the "Object identifier" without the current oid mechanism?

As near as I can tell, SQL99's idea of OIDs has little to do with ours
anyway.  Note that they want to assign an OID to an "instance of an
abstract data type".  Thus, if you created a table with several columns
each of which is one or another kind of ADT, then each column value
would contain an associated OID --- the OID is assigned to each value,
not to table rows.

My suspicion is that SQL99-style OIDs would be implemented as a separate
counter, and would be 8 bytes from the get-go.

> What's wrong with 64-bit oids (except extra 4bytes)?

Portability, mostly.  I'm not ready to tell platforms without 'long
long' that we don't support them at all anymore.  If they don't have
int8, or someday they don't have SQL99 OIDs, that's one thing, but
zero functionality is something else.

I'm also somewhat concerned about the speed price of widening Datum to
8 bytes on machines where that's not a well-supported datatype --- note
that we'll pay for that almost everywhere, not only in Oid
manipulations.
        regards, tom lane