Thomas G. Lockhart wrote:
>
> > > btw, to implement "(a,b,c) OP (d,e,f)" I made a new routine in the parser called
> > > makeRowExpr() which breaks this up into a sequence of "and" and/or "or" expressions.
> > > If lists are handled farther back, this routine should move to there also and the
> > > parser will just pass the lists. Note that some assumptions have to be made about the
> > > meaning of "(a,b) OP (c,d)", since usually we only have knowledge of the behavior of
> > > "a OP c". Easy for the standard SQL operators, unknown for others, but maybe it is OK
> > > to disallow those cases or to look for specific appearance of the operator to guess
> > > the behavior (e.g. if the operator has "<" or "=" or ">" then build as "and"s and if
> > > it has "<>" or "!" then build as "or"s.
> >
> > Sorry, I forgot something: is (a, b) OP (x, y) in standard ?
>
> Yes. The problem wouldn't be very interesting otherwise :)
Could we restrict OPs to standard ones (like we do for subselects) - I don't
like assumption about ORs for operators with "!" ?
"Assume as little as possible" is good rule...
Vadim