WG: [HACKERS] newoid in invapi.c

There is simply very much that speaks against the use of oid's a la long.

Yes I agree that the way oids are implemented now has problems.
However I choose to see these problems as "implementation details".

No, here I disagree, a globally unique identifier like oid is an architecture and strategy thing.
As such it needs a lot of thought and care.

Illustra defines a "reference" maybe we should dig into that ?
create table person (
name char (16),
mother ref(person),
father ref(person)
)

Ok, if such a reference is unique within a table then we've got something
similar to tids if they are not they would more resemble oids.
I don't know which is the case for illustra but recalling it's
heritage...?!?

Illustra uses oid's, and of course it suffers the same bottleneck on a multi CPU System.

I presume that illustra would allow me to extend the above like in the
following:

create table teacher (
course char (32)
) inherits (person);

Yup, syntax is: create table teacher (course char(32)) under person;

If the illustra system allows me to insert a teacher object as my
mother then the illustra reference is not likely to be implemented as
physical

No, in the above schema the teacher instance gets its own identity, same as postgresql.

reference (tid) but more likely with some logical reference (oid).

I really hope the last suggestion is the case as it would much
resemble that which I would like to see in postgresql.

A unique pointer to a row for me is always:
dbid + tableid + fileid + primary key (or even rowid)

In a relational system, yes. In a OO system not necesarily.
Because as in the example above, a lady who happens to be my mother
may also happen to be a teacher. The identity of "my mother" and the
identity of "my mother the teacher" should be the same.

Agreed, but currently not the case. Let me explain further:
If you have parents, teachers under parents and petowners under parents :-).
Then the teachers that are also petowners would get 2 oid's. One for teacher
and one for petowner. I agree that this is not perfect, and can not be solved with the current
architecture :-(

It would be a pity is "my mother" would have two identities just because
of the way my database system stores it's data.

I personally like the idea of a physical address as an alterntive to oid.

The problem

with this is that physical position changes over time. As the past has

shown the

same problem is also present for oid's. The problem could maybe be solved
with a physical position tracking system, that gets reset at vacuum time.

Or maybe

the existing logic for indexes could be reused in a somewhat modified

manner.

I'm not trying to say that the physical address approach to identity is
wrong.
I'll try to explain with an example.

<EXAMPLE>
CREATE TABLE base (f1 int4);
CREATE TABLE derived (f2 int4) inherits(base);

INSERT INTO base values(10);
INSERT INTO base values(20,20);

How would you know, that this is an entry for the derived subclass ?

</EXAMPLE>
.....

This of course as a result of the so-called "is_a" relation between
instances of the
derived class and instances of the base class.
So the query is polymorphic because it also operates on instances of classes
derived from the base class.
So to support polymorphism we need to have some form of identity which
is also valid between tables. As a result the current tids in postgresql
won't work because they are only valid within one table.

simply add the table id to the tid ?

You'll have noticed that my "ideal" system has different semantics
than postgresql. So as far as I concerned there is room for improvement
in postgresql.

According to me in the least triggers, indices and select/update/delete
statements should be polymorphic
(should work for instances of base classes and instances of derived
classes).

The successor of Illustra, the Informix Universial Server does this.
We have a comment in the code stating that the base* should probably be the default.
Looks like others think that way too. :-)

In short:
1. I think your work in the current direction is very valuable !
2. I still suggest to implement it in a way that leaves the door open
to not have an oid for every table/tuple per default.
3. Tables without oid would simply not have all the OO functionality.
tuples without the oid would not exist in the *OO world*
4. I think it is valuable to have both OO and fast relational stuff. (ORDBMS)

Andreas