Adriaan Joubert wrote:
>
> 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.
This could be fixe by going to Mariposa-style double-length oids, that have
first 4 bytes as "site-id" and the rest is our conventional oid.
and then just maintain an /etc/postgresql-max-oid file that holds the site-id
which is incremented at each initdb.
If you are gong to do real distributed DBs you have to set up some registry
for
allocating site-id ranges, so format for /etc/postgresql-max-oid might be
max-used-site-id max-site-id
> And a lot of the OO work on postgres would then depend on providing efficient
> ways of handling these keys.
Yes, but these keys _are_ currently the oids
--------------
Hannu