Re: AW: [HACKERS] Re: Subselects open issue Nr. NEW

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