Chris Bitmead wrote:
> Peter Eisentraut wrote:
> >
> > Independent of everything else I would like to point out that although
> > oids do appear in a central role in the theory of object oriented
> > databases they are still not a user-level feature.
>
> Yes and no. Any useful ODBMS will allow you to get at the oid. This
> allows you to say, pass it over a network as a key that you can use
> later to get at the object.
I'm starting to think that an oid is totally the wrong key to use for an
ODBMS. As objects
are only accessed via a client library there is no reason why this could not
add a key field.
You could then have a new system table that maps key fields on physical
locations, specific
types and whatever else you may need.
That would also make it easier to ensure keys being consistent between dumps.
Imagine wanting
to load some tables into an existing database and some of the oids of your
objects have been used already.
If you have overlapping key sets it is much easier to update those with an
increment to make them
unique rather than to try to get all your oids consistent, isn't it?
And a lot of the OO work on postgres would then depend on providing efficient
ways of handling
these keys.
[Please flame when talking rubbish]
Adriaan
