Thoughts on inheritance docs

A few observations here.  Want to get feedback before considering
proposing a documentation update here.

The first is that the only example given for table inheritance is a
set/subset model, and the example is problematic for the reason that
the caveats section discusses.  Consequently it isn't immediately
apparent how table inheritance (and in particular multiple inheritance
which, unless I have missed something, seems to be unique to
PostgreSQL).

In general, I see table inheritance as useful for a large number of
tasks including:

  * Set/subset modelling (here borrowing techniques from table
partitioning is necessary-- the full set is partitioned according to
interesting subsets, but each subset may extend associated info)

  * Enforcement of consistent semantics of join syntax, including
functions that would allow you to automatically traverse joins.
Consider:  SELECT (bc.inventory_item).sku from barcodes bc where the
inventory_item method is inherited from inventory_item_ref.  Since
inventory_item_ref would add a column called inventory_item_id to the
table, we'd also know join syntax would generally be consistent.

  * Derivative information modelling of sets of columns which are
insufficient for relational modelling by themselves
     (perhaps because they lack necessary join conditions)

To my knowledge, the latter two are PostgreSQL-specific.  They make
very little sense unless multiple inheritance is permitted, and every
other ORDBMS I have looked at (including Informix, DB2, and Oracle)
has only supported single inheritance.  Restricting to single
inheritance makes sense if you are specializing on set/subset
modelling but multiple inheritance is a tremendously useful tool that
may be well beyond cutting edge.  it might be worth showing this off
in the documentation with real, working examples.

So my questions:

1)  Would it be worth coming up with more useful examples for table inheritance?
2)  Would it be worth adding mention of uses of multiple table inheritance?
3)  Would it be worth discussing how to position the limitations of
table inheritance?  I personally recognize the difficulties in
documenting these but I can't help thinking that a simple chart of
"this is/is not inherited" would be very useful as well.

What do people think?

Best Wishes,
Chris Travers