Re: Inheritance - Mailing list pgsql-hackers

On Mon, 2002-08-19 at 09:42, Curt Sampson wrote:
> On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote:
>
> > > So what you're saying is that constraints shouldn't be inherited?
> >
> > No. I even said that inheriting should be the default.
>
> Ah. So you think it should be possible not to inherit constraints.

I've been silent for a bit because I wanted to kick the concept around
in my head.  After some thought, I say that I support children
inheriting constraints.  In a more abstract sense, we are really setting
conditions for all entities of a given type (class) which must be met to
classify as a defined type.  Again, in an abstract sense, if I say all
"candies" (type/class, candy) must have sugar (constraint), and I go on
to create a subclass of candy which I desire not to have sugar, then
there is a fundamental problem.  Either I incorrectly identified my
problem domain and didn't properly create my entities which address my
domain needs or what I'm trying to express really isn't a candy at all.
In other words, it sounds like candy should of been a subclass of a more
abstract base entity.  Likewise, the newly desired class which doesn't
have sugar should also inherit from the newly created base class and not
be derived from candy at all.


>
> > A local constraint should be made obvious from looking at the schema,
>
> Ok, this now I could live with. Though I'm not sure that its
> theoretically very defensible, or worth the effort. Other languages
> that offer constraints, such as Eiffel (and soon Java), do not allow
> constraints that are not inherited, as far as I know. Do you have some
> counterexamples.

I tend to agree.  Constraints should be inherited.  See above.

>
> > Well, that is where I do not think this is flexible enough, and keep in mind
> > that all triggers and rules would then also need such restrictions.
>
> Yes, all triggers, rules, and everything else would have to be inherited.

Agreed.

>
> > Regardless whether your objection is *strong* or not :-)
> > If you don't like the feature (to add a local constraint), don't use it.
> > (Remember you are talking about removing an implemented feature)
>
> 1. It's not exactly an implemented feature, it's an accident of an
> incomplete implementation of inheritance done in a certain way.
>
> 2. Should we change the way we decide to implement inheritance,
> perhaps to make fixing the current problems much easier, it might
> be a lot of work to add this.
>

I'm still trying to figure out if subclasses should be allowed to have
localized constraints.  I tend to think yes even though it's certainly
possible to create seemingly illogical/incompatible/conflicting
constraints with parent classes.  Then again, my gut feeling is, that's
more and an architectural/design issue rather than a fundamental issue
with the concept.


--Greg Copeland