> We could make that restriction directly (just resolve the operators,
> and then complain if the resolver chooses different types for A),
> but it might make more sense to first coerce B and C to be the same
> datatype, eg using the same rules that UNION/CASE do. If we did that
> then BETWEEN would only need to keep track of two comparison operators
> not four (the asymmetric case requires four distinct comparison ops
> if B and C are not the same datatype).
>
> Comments anyone?
*sigh* This is getting a bit out of my league... I seem to have a habit of
picking things to work on that turn out to really need a total rethink ;)
> BTW, would you go screaming off into the night if I pointed out that
> SQL92 expects BETWEEN to support row-wise comparisons? Really this
> project should include upgrading our support of row-wise comparisons
> to be spec-compliant. Right now, gram.y transforms them into something
> (see makeRowExpr) that looks plausible but does not actually implement
> the spec-required semantics. I suspect we need RowComparison nodes to
> go along with Between nodes.
I don't quite understand the exact issue, but I'll try to read up on it.
However, expect delays in implementation.
OK, how about I firstly submit a patch that adds support for SYMMETRIC and
ASYMMETRIC using the old style hack. Actually - I think I've already
submitted that patch. Then, once that's in, I/we can hack on the new style
one at our leisure.
Chris
