Re: DROP COLUMN misbehaviour with multiple inheritance

Tom Lane kirjutas R, 20.09.2002 kell 04:49:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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