OIDS (Re: [HACKERS] Well, then you keep your darn columns) - Mailing list pgsql-hackers

From Peter Eisentraut
Subject OIDS (Re: [HACKERS] Well, then you keep your darn columns)
Date
Msg-id Pine.LNX.4.21.0001260034440.9535-100000@localhost.localdomain
Whole thread Raw
In response to Re: [HACKERS] Well, then you keep your darn columns  (The Hermit Hacker <scrappy@hub.org>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: AW: AW: [HACKERS] Some notes on optimizer cost estimates
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Inheritance, referential integrity and other constraints