Re: SQL3 UNDER - Mailing list pgsql-hackers

"Robert B. Easter" wrote:
> 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.

As far as I'm concerned, current postgres INHERIT, is exactly the same
semantics as UNDER (apart from multiple inheritance). That being the
case, the only point of retaining INHERIT is legacy. Encouraging use of
a completely different syntax just for multiple inheritance seems
foolish.

If you think the semantics are different provide a specific example
(including SQL) of how you think their behaviour is different - that is
how you think UNDER should work differently to current INHERIT.

> (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)?

That kinda sounds like how SQL3 describes the model. But it doesn't mean
we have to implement it that way to provide the same behaviour. And in
fact we don't, and I don't think we should either.

> 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.

What you have just described for the behaviour of UNDER (as opposed to
implementation) is just how INHERITS works now. i.e. you can't destroy
the parent unless there are no children. While I think the ability to
destroy a parent would be a good feature (for evolving a schema for
example), it hardly amounts to a whole new model. The time to decide you
want the ability to destroy a parent, is when you've decided to destroy
a parent, not when you created a child. As far as I'm concerned, the
more wierd and wonderful ways to evolve the schema without destroying
data the better.

In general, I think you concentrating too hard on implementation as
opposed to semantics. Try to crystalise the semantics first, then
implementation can be chosen on performance.