Re: SQL3 UNDER

Mr. Bitmead,

I read your patch (but have not applied it, or tested it exactly). It says
that UNDER supports multiple inheritance as a Postgres language extension. How
about instead, implementing UNDER exactly to the SQL3 spec? For multiple
inheritance, why not just suggest the use of INHERITS, which is
already a Postgres language extension for multiple inheritance. UNDER covers
the tree/hierarchy situation, so make it only to SQL3 standards.
INHERIT fits the clone/copy/inherits situation that, like I've
said before, is like starting a new tree. You could constrain INHERITS to only
accept tables that are maximal supertables. INHERITS probably should not
accept a subtable that is within an UNDER tree - that would add much
complication if allowed. I know that I said that maybe INHERITS should strive
to become UNDER in a prior message. But now I can see exactly how they
complement each other: each provides a different type of inheritance scheme.

(sorry if I seem to keep saying the same things over and over ... again..)
In UNDER, the tables are connected into a tree like one big table with
extensions to it (the subtables). The subtables are dependent on the
supertables so that the supertables cannot be dropped until you drop all its
subtables first. My impression of the subtable-supertable relationship is
that, again, the subtable stores only the subrow it declares. The subrow it
inherited from its supertable is just a link. When inserting, the subtable
stores the subrow it declared, then it accesses its supertable
and inserts the inherited subrow. The subtable is incomplete without accessing
its supertable for the inherited subrow. When you add a column to a superclass,
there should be no need to also add a column to the subclass. The subclass
doesn't store it, but should just begin accepting the new attribute of its
superclass. Isn't this how the SQL3 spec works (I'll have to read it more)?

INHERITS should accept only maximal supertables or tables that are not
part of an UNDER tree. The child table could be independent of the parent
table. The parent table could be dropped without consequence to the child
table since it inherits a copy of all its parent's attributes. While the
parent exists, it would maintain information about all of its children
tables so that it can select down into them (in common attributes only). The
child maintains no linkage to the parent - its inserts etc only affect itself.
This contrasts with UNDER, where a subtable does maintain a link to its
supertable in order to cascade inserts etc to the supertable for the subrow it
inherited.

I hope my comments are helpful! :)

On Mon, 22 May 2000, Chris Bitmead wrote:
> For those interested I've extended the patch to support the SQL3 UNDER
> syntax...
>
> ftp://ftp.tech.com.au/pub/diff.x
--
Robert B. Easter
reaster(at)comptechnews(dot)com