Re: Inheritance - Mailing list pgsql-hackers

On Fri, 2002-09-06 at 07:53, Hannu Krosing wrote:
> On Fri, 2002-09-06 at 09:53, Curt Sampson wrote:
> > This looks like a classic case of incorrect modelling to me. Does the
> > good itself change when it becomes a campaign_good? No. The price
> > changes, but that's obviously not an integral part of the good itself.
>
> Perhaps we mean different things by good. I meant a GOOD to be a THING
> bought with the purpose of reselling. Price (actually prices:
> selling_price and buying_price) is what makes it a GOOD and thus it is
> an integral part of it.

No matter now you look at the example, invalidating it does not address
the issue raised as it still exists.  Either way, Hannu and I seem to
agree that some class of constraints need to be able to be overridden.

> In case of being able to override constraints for child tables it can
> also be a significant performance boost - if you have 10 000 000 goods
> in a table you don't want to change a constraint on GOODS to allow
> campaign goods to be sold cheaper than bought as it would have to check
> all goods for validity according to new constraint - putting the
> constraint on just CAMPAIGN_GOODS will enable the DB engine to check
> just tuples in CAMPAIGN_GOODS.

I had not considered this before.  Does that still hold true if we go
with a parent contains all columns implementation?  Of are you simply
saying that it doesn't matter as when the constraint were applied it
would only scan the rows the below to the child?  Perhaps this doesn't
matter for this portion of the conversation.  But hey, I was curious.
:)

>
> > > SQL standard constraints should be non-overridable. I still think that
> > > Constraint triggers should be overridable/dynamic.
> >
> > I still don't like it. Eiffel had good reasons for making the
> > constraints non-overridable. Other OO languages don't have constraints,
> > or they would probably do the same.

Well Curt, as you outlined above (clipped out) about it being a
different world...I think also applies here.  IMO, we are treading
lightly on new and perhaps thin ground so we need to be careful that we
apply common parallels and idioms only we are certain that they need
apply.  What I'm trying to say is, just because it's not allowed in
Eiffel does have to mean the same applies here.

> >
> > That said, I could live with dynamic dispatch, if the default were
> > to make it non-dynamic, and you had to add a special flag to make it
> > dynamic. That way it would be obvious to the casual user or a DBA
> > familiar with other databases but not postgres that something unusual is
> > going on.
>
> That seems about the right compromise between constraining and developer
> freedom.
>

I agree.  That does appear to be pointing us in a conservatively sane
and safe direction.


Greg