Hiroshi Inoue wrote:
>
> The analog of ROWID in PostgreSQL is TID rather than OID
> because TID is a physical address of a tuple within a table.
> However there's a significant difference. Unfortunately TID
> is transient. It is changed by UPDATE and VACUUM.
> Though TIDs are unavailable for critical use, OIDs could
> compensate the drawback. TIDs and OIDs must help each
> other if PostgreSQL needs the concept like ROWID.
That is true now, but I am saying that it should not be true. Rather than have
a single limited global resource, the current OID, if possible, tables should
get their own notion of an OID, like a ROWID.
The ability to eliminated OID from tables is a great step, but, if one needs a
OID behavior on tables, then one has a limit of 2B-4B rows in an entire
database system for which all tables compete.
You have even said you need the notion of an OID for some ODBC cursor stuff you
are doing. Thus eliminating OIDs is not an option for you.
The options are:
No OID on a table. This breaks any code that assumes an OID must always exist.
Use OIDs on a table. This limits the size of the database, I have already had
to drop and reload a database once because of OID depletion (3 months).
If OIDs can become the equivalent of a ROWID, then code designed that assumes
OID are always valid will still work, and Postgres will not run out of OIDs in
system wide sense.
I know I won't be doing the work to make the changes, so I am sensitive to that
issue, but as a PostgreSQL user, I can say that I have hit the OID limit once
already and will continue to hit it periodically. Getting rid of OIDs may not
be an option for me because I planning to do some replication across several
boxes, and that means I would use OID or use a sequence and "default
nextval(...)."
--
5-4-3-2-1 Thunderbirds are GO!
------------------------
http://www.mohawksoft.com