Thomas G. Lockhart <lockhart@alumni.caltech.edu> wrote:
> > But yes, I agree that the left-right approach would be intuitive (same as
> > compound index).
> > In mathematics it is called lexical order, I only thought this would be hard
> > to implement.
> > Also there are a lot of operators (all negated Op's that) will want an _OR_
> > e.g. !=~, not only <>
> We had started discussing this back when we implemented the general SQL92
> syntax for multiple left-hand arguments in expressions.
> One possibility was to make the generalization that any operator with "!" or
> "<>" (others too?) in the operator string would be handled as a negation, and
> all others otherwise. Then, many operators would "magically" work correctly or
> intuitively, while a few, perhaps, would not behave correctly. However, imho
> this is preferable to not allowing _any_ of these, and perhaps we would learn
> over the next few months a way to tighten it up...
> - Tom
Hi,
I think we can handle all operators in one general way,
something like this:
for (i = 0; i < n-1; i++) /* (n-1) iterations here. */
{
if (a[i] is NULL || b[i] is NULL)
return UNKNOWN; /* three-value boolean logic. */
else if (a[i] == b[i])
continue;
else
return (a[i] op b[i]);
}
return (a[n-1] op b[n-1]); /* the last n-th iteration. */
Works well for all standard ==, !=, <, <=, >, >=.
The problem appears if someone would define an operator like
"approximately equals". An operator of this sort should
replace the operator == in the above pseudo-code.
Also someone could have operator "approximately less than"
which uses "approximately equals" as operator == in the above
along with ordinary operators < and ==.
So the problem seems can be solved if we assume that both
operator == and operator op in the above are parameters.
The proposed syntax for tuple comparison predicate could be
(a1, a2,...) [USING EQUALS OPERATOR [op2]] op (subselect)
with op2 defaults to:
op, if "USING EQUALS OPERATOR" is specified,
"==" otherwise.
Any comments ?
To have much more cool object-oriented spirit we could allow
operator overloading for tuples. Let's leave it until later...
--
Yurik
