> As a rule, anything that applies to a base class should also apply to
> the sub-class automatically. For some things you may want to have the
> option of excluding it, by something like the ONLY syntax of select, but
> 99% of the time everything should just apply to sub-classes.
That makes sense. I assume that you cannot remove the unique constraint
that
a parent provides, once those start being inherited. This is mostly because
foreign key references really only work in the presence of a unique
constraint.
> Storing oids of attributes sounds like a problem in this context because
> it may make it hard to relate these to sub-classes. I do really think
> that the system catalogs should be re-arranged so that attributes have
> two parts - the parts that are specific to that class, and the parts
> that also apply to sub-classes. For example the type and the length
> should probably apply to sub-classes. The attnum and the name should
> probably be individual to each class in the hierarchy. (The name should
> be individual to support subclass renaming to avoid naming conflicts,
> like in the draft SQL3 and Eiffel). If it is in two parts then using the
> oid of the common part would make it easy for your purposes.
How would one refer to an attribute whose name has changed in a
subclass if you're doing a select on the superclass (or do you even
need to do anything - does it figure it out automagically?)
