> So maybe we'll get rid of the oid and introduce some other "thing" with
> also gives us identity for instances of classes.
> But IMO no identity equates to no OO. And currently identity is only
> provided
> by oids, so I would vote to keep them in user tables too.
In relational speak a tuple is always identified by it's primary key, which also guarantees
fast access. The where oid = <value> is only fast if the user defines an index on oid.
The extensive use of oid's is also a nightmare for all those that want to reorganize tables.
There is simply very much that speaks against the use of oid's a la long.
Illustra defines a "reference" maybe we should dig into that ?
create table person (
name char (16),
mother ref(person),
father ref(person)
)
A unique pointer to a row for me is always:
dbid + tableid + fileid + primary key (or even rowid)
I personally like the idea of a physical address as an alterntive to oid. The problem
with this is that physical position changes over time. As the past has shown the
same problem is also present for oid's. The problem could maybe be solved
with a physical position tracking system, that gets reset at vacuum time. Or maybe
the existing logic for indexes could be reused in a somewhat modified manner.
Andreas