Tom Lane kirjutas R, 20.09.2002 kell 04:49:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Christopher Kings-Lynne wrote:
> >> Has anyone given much thought as to perhaps we could just drop multiple
> >> inheritance from Postgres?
>
> > I am for it. Multiple inheritance is more of a mess than a help.
>
> I'm not agin it ... but if that's the lay of the land then we have
> no need to apply a last-minute catalog reformatting to fix a
> multiple-inheritance bug.
What I'm actually envisioning for PostgreSQL inheritance is model
similar to (my understanding of) SQL99 :
1. Single "data" inheritance for SELECT/INSERT/UPDATE/DELETE , meaning
that the set of inherited tables any such command operates on comes from
a single-inheritance hierarchy
the SQL99 syntax for defining tables is
CREATE TABLE child (
...
) UNDER parent;
2. This single inheritance also applies both to "tuple-level"
constraints (not null, check) and to "relation-level" constraints -
unique, primary and foreign keys.
3. Multiple "interface-only" inheritance
the SQL99 syntax for defining tables is
CREATE TABLE child ( ..., LIKE othertable, LIKE yetanothertable,
);
which would behave like our current multiple inheritance, only without
affecting SELECT/INSERT/UPDATE/DELETE and "relation-level" constraints.
4. "tuple-level" constraints should still be inherited
5. function selection for functions defined on row typoes should be able
to select both from among functions defined over "data" inheritance
parents and "interface-only" inheritance parents.
5 such selection should be dynamic (scan-time) for queries running over
inheritance trees. (SELECT without ONLY , formely SELECT*)
> This patch is off the "must fix for 7.3" list, no?
I still think that this should be fixed in 7.3, but the inhcount
attribute should show all tables where the column is defined, not just
inherited. The default, no-inheritance case should set the column to 1.
-------------
Hannu