Re: [HACKERS] newoid in invapi.c

-----Original Message-----
From: Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
To: 'pgsql-hackers' <pgsql-hackers@hub.org>
Date: dinsdag 10 maart 1998 16:26
Subject: 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.

Yes, you are right, it does.

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

What a pity.


>
>>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 :-(
I want to think about this for a while. Maybe there is some cleverness to be
found.
>
>>It would be a pity if "my mother" would have two identities just because
>>of the way my database system stores it's data.
>>>

<snip>
>>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 ?
Might work.
>
>>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. :-)
Doesn't the "Postgresql Universal Server" sound nice?
>
>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)
>
Your points have been taken.

Thanks,
Maurice.