WG: [HACKERS] newoid in invapi.c
От | Zeugswetter Andreas |
---|---|
Тема | WG: [HACKERS] newoid in invapi.c |
Дата | |
Msg-id | 01BD4C0D.233E1940@pc9358.sd.spardat.at обсуждение исходный текст |
Список | pgsql-hackers |
>>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
В списке pgsql-hackers по дате отправления: