Re: OIDS (Re: [HACKERS] Well, then you keep your darn columns)
От | Hannu Krosing |
---|---|
Тема | Re: OIDS (Re: [HACKERS] Well, then you keep your darn columns) |
Дата | |
Msg-id | 38901D79.9EB20738@tm.ee обсуждение исходный текст |
Ответ на | OIDS (Re: [HACKERS] Well, then you keep your darn columns) (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: