Oliver Elphick wrote:
> If we do allow differences, I think that they should not depend on the
> user's remembering to add * to the table name. I think that an
> alteration to a parent table alone should require a UNINHERITED keyword
> to make the intention explicit. (After all, the user may not realise
> that the table is a parent; I think the RDBMS should protect him against
> obvious traps.)
I agree, and think that the "*" is a trap in general. Which is why I
suggest we go the Informix/Illustra route and dump "*" altogether,
replacing it with "ONLY" or some such, when you don't want inherited.
> Perhaps we need a concept of grouped indexes to go with the grouped
> tables that inheritance creates. Clearly this is one of the issues
> that the original designers didn't think through. If we consider the
> uses of an index, we can see that it is used first for fast access to
> tuples and second to enforce uniqueness. If (as I am suggesting)
> the constraints that require an index (PRIMARY KEY, REFERENCES and UNIQUE)
> are forced to be group-wide, it will follow that the corresponding
> indexes should also be group-wide. On the other hand, a user-created
> index for fast access could apply to a single table in the group.
I think indexes too should be inherited (physically as well as
logically) unless you choose the ONLY keyword.
> a (id char2 primary key, name text not null)
> b (tp char(1) not null default 'B', supplier text) inherits (a);
> c (tp char(1) not null default 'C', customer text) inherits (a);
>
> It seems quite a sensible use of inheritance to allow different defaults
> for tp in tables b and c. However, we then have difficulty here:
>
> d (c1 text) inherits (b,c)
>
> Which tp is to be inherited? At present, PostgreSQL avoids the problem
> by not inheriting any constraints. We need something like:
>
> d (c1 text) inherits (b,c) using b.tp
Hmmm. I don't think that's right at all. For example tp might be a
different type in b and c, and code might depend on that. It would be
logically unreasonable to have an inherited "d" not have BOTH tp from b
and c. I think from memory, Eiffel solves this by renaming doesn't it? I
think you need either renaming or scope resolving syntax. This would
probably get very messy, and I think it's probably quite sufficient to
force the user to not inherit the same name from b and C. If you want
that, you have to rename tp to be something else in b and/or c.
> Final note: I have just realised that most of what I am using inheritance
> for could be done with views and unions, provided that we can REFERENCE a
> view (which I haven't tested). One really radical option would be to strip
> out inheritance altogether!
Please no! Yep, inheritance in SELECT is actually implemented as a UNION
internally. But don't dump it!