Re: [HACKERS] newoid in invapi.c - Mailing list pgsql-hackers

-----Original Message-----
From: Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
To: 'pgsql-hackers@hub.org' <pgsql-hackers@hub.org>
Date: dinsdag 10 maart 1998 0:36
Subject: Re: [HACKERS] newoid in invapi.c


>> So maybe we'll get rid of the oid and introduce some other "thing" with
>> also gives us identity for instances of classes.
>> But IMO no identity equates to no OO. And currently identity is only
>> provided
>> by oids, so I would vote to keep them in user tables too.
>
>In relational speak a tuple is always identified by it's primary key, which
also guarantees
>fast access.
Yes, in relational speak it is.

>The where oid = <value> is only fast if the user defines an index on oid.
>The extensive use of oid's is also a nightmare for all those that want to
reorganize tables.
>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".

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

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

create table teacher (
 course char (32)
) inherits(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
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.
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);
</EXAMPLE>

For the query "SELECT <identifier>,f1 from base;" my ideal OO system
might give:

<QUERY OUTPUT>
18400, 10
18401, 20
(2 rows)
</QUERY OUTPUT>

For the query "SELECT <identifier>, f1 from derived;" my ideal OO system
might give:

<QUERY OUTPUT>
18401, 20
(1 rows)
</QUERY OUTPUT>

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.

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

Thanks, with regards from Maurice.