Обсуждение: Inheritance Semantics

Could someone (Chris Mead?) post an update on the status of fixing
PostgreSQL's inheritance semantics in the following ways:

Has a decision been made to implementing true inheritance via INHERITS or an
alternative keyword?

By true inheritance, I mean first and foremost that any query on a super-class
should query *all members* of that class by default regardless of which table
they are stored in.  Any other behavior violates the very natural expectation
that a table called "PERSON" actually implements the class of all persons.  

Second, for performance reasons, there needs to be a way for an index on a
parent class attribute to be shared by all the tables that implement or
inherit from that parent class.  This is also necessary to enforce unique
constraints on all members of a class.

I imagine that the current implementation of "SELECT column FROM table*" is a
logical UNION ALL of the select statement applied to each sub table, using
different indexes for each one - Is this correct?

Third, all declarative constraints on a parent class should be enforced
against all members of all sub-classes without exception.  

Fourth, someday it would be nice to be able to create object methods & member
functions that operate in the context of a single object.  Does anyone know if
the OQL supports this capability?

I understand the backwards compatibility issue with the current semantics. 
Rather than adding some sort of run-time setting, I think it would be much
better to add a new keyword / extension to the DDL syntax so that true ODMG
style inheritance can be implemented correctly without breaking old
applications.

Any comments would be appreciated.
- Mark Butler

> Could someone (Chris Mead?) post an update on the status of fixing
> PostgreSQL's inheritance semantics in the following ways:
> 
> Has a decision been made to implementing true inheritance via INHERITS or an
> alternative keyword?
> 
> By true inheritance, I mean first and foremost that any query on a super-class
> should query *all members* of that class by default regardless of which table
> they are stored in.  Any other behavior violates the very natural expectation
> that a table called "PERSON" actually implements the class of all persons.  
> 

7.1 does that already.


> Second, for performance reasons, there needs to be a way for an index on a
> parent class attribute to be shared by all the tables that implement or
> inherit from that parent class.  This is also necessary to enforce unique
> constraints on all members of a class.

That is on the TODO list, so I think we want it to happen.


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Hey Bruce,

Your book finally hit the bookshelves of Staten Island.
We have a Barnes and Noble here that actually has a reasonable
database section although it is misnamed 'Networking'.  ;-)
I'll be getting my copy on payday - I found the sql examples
that I downloaded very useful and as I've been running Pg in
production since 6.3.2 I'd like to support the project.

I have a question as well.  Any chance you folks or Great Bridge
would offer Pg*DBA certification exams?

Cheers,
Tom
--------------------------------------------------------------------              SVCMC - Center for Behavioral Health
               
 
--------------------------------------------------------------------
Thomas Good                          tomg@ { admin | q8 } .nrnet.org
Database Administrator               Phone: 718-354-5528 
Staten Island Region                 Fax:   718-354-5056  
--------------------------------------------------------------------
Powered by:  PostgreSQL     s l a c k w a r e          FreeBSD:              RDBMS       |---------- linux      The
PowerTo Serve
 
--------------------------------------------------------------------
                  /* Jeder Jeck ist anders! */