From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Chris Bitmead <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au> |
Cc: | "Robert B(dot) Easter" <reaster(at)comptechnews(dot)com>, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'Postgres Hackers List'" <hackers(at)postgresql(dot)org> |
Subject: | Re: AW: Postgresql OO Patch |
Date: | 2000-05-25 04:11:39 |
Message-ID: | 392CA7FB.CB484331@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael A. Mayo | 2000-05-25 04:54:38 | Re: [SQL] |
Previous Message | Lamar Owen | 2000-05-25 03:49:56 | Good article on linux.com about PostgreSQL (sortof). |