Thread

  1. Re: [HACKERS] newoid in invapi.c

    Maurice Gittens <mgittens@gits.nl> — 1998-03-10T18:53:46Z

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