Re: foreign key constraint versus referential integrity constraint
Date: Tue, 27 Oct 2009 07:22:44 -0700 (PDT)
Message-ID: <0cbff3b0-cb11-47a6-a33c-3f68afb28347_at_v37g2000prg.googlegroups.com>
On Oct 26, 10:29 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Marshall wrote:
>
> >>>In a typed system, the type is whatever the intersection
> >>>of int and string is.
>
> >>Union not intersection. It has to be a type compatible with both integer
> >>and string.
>
> > I don't see how that would work. An integer isn't type compatible
> > with a string. Is it?
>
> It doesn't have to be compatible with a string. It only has to be
> compatible with TOP or the universal supertype. String doesn't have to
> be compatible with integer either. It only has to be compatible with TOP
> or the universal supertype.
OK, I didn't get much sleep last night so I'm not very sharp, but
I'll just regurgitate the argument I thought of before I went to
bed:
Consider relations A and B each with a single, common attribute.
Natural join and inner union will behave much like intersection
and union in this case. If the result type of the join isn't an
intersection type, then we lose the property:
A = A join (A union B)
because the type of the attribute of the expression is different
than the type of the attribute of A.
More generally, the values in the result of a join are the
intersection
of the values in the operands; why wouldn't the result type be the
intersection type?
> > Fortunately, I'm not hot any more. Now I'm thinking that
> > I haven't had any alcohol in a week or more. Maybe
> > a drink is in order? Plus, I think there is a cupcake in
> > a cupboard somewhere downstairs. I must away!
>
> Having bathed each of my 3 dogs several times, I now have to wash the
> skunk smell out of the vestibule before it pollutes the house any more
> than it already has, when I would much rather just go to bed.
Marshall Received on Tue Oct 27 2009 - 15:22:44 CET