Re: Unique Keys

Kenneth Downs wrote:
> > Yes, but only by subverting the traditional meaning of "equals"!
So
> > what do you do now if you want to know if the 2 DATEINTERVALs
really
> > are the same?
>
> Perhaps you would be more comfortable with the OO term? Operator
> Overloading?

I don't object to the term. But if you define your overloaded operator "=" such that when applied to two DATEINTERVAL values it merely checks that they overlap, what operator would you use to check whether they are trully equal? You can't overload an operator such that it works more than one way for the same data types, only so that it works differently for different data types.

I do object in principle to overloading operators in counter-intuitive ways!
"a = b" means "a equals b" means "a has the SAME value as b".

And I still have no idea what rule your foreign key is supposed to implement! It seems to say that every child record must overlap some parent record. Is that useful? Received on Fri Nov 26 2004 - 14:12:40 CET