Adriaan Joubert wrote:
> 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.
I don't know what that means.
> 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?
In general, moving objects between databases depends what you want. One
approach is that the oid contains some bits related to the database it
was first created in. The other approach is to re-link all the objects
when they are imported. (By incrementing them by a fixed amount given
the current max(oid) is one way).
> And a lot of the OO work on postgres would then depend on providing efficient
> ways of handling
> these keys.
??