Re: AW: Postgresql OO Patch

Chris Bitmead wrote:
> 
> "Robert B. Easter" wrote:
> 
> > > Imho this alone more than justifies the patch.
> > > We should also change our keyword "inherits" to "under".
> > >
> >
> > I don't agree.  UNDER only provides for single inheritance according to spec.
> > Making it multiple inherit would break UNDER's basic idea of enabling hierarchy
> > trees that contain subtables under a single maximal supertable.
> 
> I don't see that it's a "basic idea". I see it as crippled subset of
> SQL3-94.

Me too.

OTOH single inheritance has the advantage that it can be implemented
with _all_ 
subtables stored in single "physical" table, whereas multiple
inheritance can't,
which makes sharing thinkgs like primary keys and other constraints much
easier 
to implement as well.

> > You use UNDER when the child/subtabe to share the exact same
> > physical PRIMARY KEY of the SUPERTABLE.  In inherit, the child inherits a
> > composite key from the parents,

That composite key must actually still be two unique key (and thus
doube-uniqe ;)
which does not make much sense.

> > but that key is new physically, not the same physically as any parents.

Maybe what you are trying to accomplice by your definition of INHERITS
is 
better done by aggregation ?

create table engine (volume float);
create table wheel(circumference float);
create table car(   car_engine  engine,   car_wheels  wheel[4]
);

At least this fits better with may feeling that a car is not a "kind of"
engine.

And this should be possible with PostgreSQL now (except that type _wheel 
(for array of wheels) is not generated automatically and so only the 
following is

create table car(   car_engine  engine,   car_wheel1  wheel,   car_wheel2  wheel,   car_wheel3  wheel,   car_wheel4
wheel
);

which probably is a bug ;(

)

> Issues like primary keys are the sort of stuff that probably kept the
> committee arguing long enough they were too lazy to come to a decision.

It sure is an issue for multiple inheritance, at least when you disallow 
multiple primary keys on things that "are" both A and B.

> Myself, I'm not too interested in primary keys since they are not a very
> OO idea anyway.

Maybe not OO but useful in RDBM anyway. One could argue that table.pk ==
oid. 
And when implemented that way it would make finding an "object" in an
RDBM
very easy ;)

------
Hannu