Tom Lane kirjutas R, 20.09.2002 kell 04:49:
> Bruce Momjian <[EMAIL PROTECTED]> 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

) 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

  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.


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

Reply via email to