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