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