Re: OIDS (Re: [HACKERS] Well, then you keep your darn columns)

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.

> 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,

What does that mean?

> and b) this is not worth doing in PostgreSQL as it stands.

Why?

> 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).

The big hope I see for postgresql is to someday be a true combination of
ODBMS and RDBMS. Current commercial ODBMSes suck because their querying
sucks. Current commercial (O)RDBMS suck because their object features
really suck. There is no fundamental reason that this must be so.

> 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).

Actually no. The whole point of oids is that they don't change. Ok, some
ODBMSes fudge this sometimes, but the whole point is if you have 100
objects pointing to one object, you don't want to have to change the oid
and go patch those other 100 objects. In particular Versant uses an 8
byte oid that NEVER changes. You can even move an object from one
database to another and it STILL doesn't change. This is rather cool.

> Our oids are something different (though not sure what),

Why?

> 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.

OIDs are a pseudo user level feature in an ODBMS. They are something you
don't think about most of the time, but you DO need to be able to get at
them.