On Wednesday 2005-12-21 07:50, Karsten Hilbert wrote:
> On Wed, Dec 21, 2005 at 01:52:34PM +0100, Martijn van Oosterhout wrote:
> > On Sun, Dec 04, 2005 at 10:59:10PM -0700, Trent Shipley wrote:
> > > Relational Constraint Inheritance Algebra
> > > With regard to class and attribute uniqueness
> >
> > It's taken a while to digest this and sorry for the delay. While I find
> > the ideas intreguing there is a little voice in the back of my head
> > asking: practical applications?
>
> I would assume quite a few people would use table
> inheritance in a simple way were it available in a more
> convenient fashion: to transport fields, primary and foreign
> keys to child tables.
I am not clear on why this sort of scenario benefits more from CREATE TABLE's
"INHERITS" clause than the "LIKE" clause (assuming that LIKE copied the
appropriate table properties). Indeed, the recursive SELECT associated with
INHERITS might be undesirable.
If I understand you [Karsten] correctly then the really elegant way to do this
is with a "DECLARE" or
"DEFINE TABLE|INDEX|FOREIGN KEY|... definition_name (definition_clause)"
(The choice of DECLARE or DEFINE would depend on the SQL list of reserved
words.)
Then instantiate the declared object with something like:
CREATE TABLE|INDEX|... object_name USING definition_name.
Changes in definition (ALTER DEFINITION)should optionally cascade to
instantiated objects. Use ALTER TABLE to create variant tables. Very useful
for creating things that often get quashed and re-created, like temporary
tables and indexes. Also very useful for things that should be uniform but
get attached to many tables, like annoying ubiquitous check constraints,
indexes, or foreign keys.
