Re: [HACKERS] newoid in invapi.c
От | Maurice Gittens |
---|---|
Тема | Re: [HACKERS] newoid in invapi.c |
Дата | |
Msg-id | 011501bd4c55$df589ea0$a2fb4fc1@caleb..gits.nl обсуждение исходный текст |
Список | pgsql-hackers |
-----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.
В списке pgsql-hackers по дате отправления:
Следующее
От: "Denis V. Dmitrienko"Дата:
Сообщение: Re: [HACKERS] "Doubled" files related to cyrillic patch in 6.3 release.