On 2000-01-24, The Hermit Hacker mentioned:
> Except, as Chris Bitmead brought up, OIDs appear to be a key requirement
> in ODBMSs ... so, if we want to go what I *think* is 'next generation',
> OIDs have to be kept ...
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. The system uses them to
in essence do what some people already do with them now: use them as links
in foreign key settings. This sort of scheme is supposed to eliminate the
need for costly joins, since you already know the location of the data
(assuming that you have a scheme to map the oid to the storage location).
This past summer this sort of idea was discussed around these parts and
most of us came to the conclusion that a) OODBs are a pipe-dream at this
point in time, and b) this is not worth doing in PostgreSQL as it stands.
If we wanna become an OODBs we might as well say that now so we can start
by dropping SQL and the optimizer and the storage manager -- okay, I'm
being sarcastic (about OODBs).
However, once again, users would have no knowledge of these "oids". The
system is free to do whatever it wants in order to do its thing, in
particular it is free to *change* oids when it needs it (because when it
copies the data elsewhere it presumably needs to tag the location
differently).
Our oids are something different (though not sure what), PostgreSQL is
something different. I am by all means against breaking what oids
represent now, but incidentally I am also against them becoming (being) a
user-level feature.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden