[
https://issues.apache.org/jira/browse/CALCITE-2842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16766907#comment-16766907
]
Zoltan Haindrich commented on CALCITE-2842:
-------------------------------------------
considering IN as a binary operator might be implementation dependent...and yes
SqlNode is a "binary" operator;
but note that at the [only existing
place|https://github.com/apache/calcite/blob/883666929478aabe07ee5b9e572c43a6f1a703e2/core/src/main/java/org/apache/calcite/rex/RexCall.java#L115]
this BINARY operatorness is exploited - it's really used to check for
symmetry; and only a subset of binary operators meet that criteria.
A Binary operator of IN is not symmetric - and although in the above case it
would not cause any issue; I think that "symmetric operators" would be better
About not permitting it's usage in Rex "land"...I would think that all the
filters which are in the standard(sql2011) should have an equivalent
representation in Rex form...because "<in predicate>" is part of the sql2011
standard.
Anyway...I looked into how this could be "fixed" to not use SqlKind.IN from
HiveIn - although there are ways to do this by specifying SqlKind.OTHER or
something as the kind, and do some "ifs" in the rules/etc instead of checking
for the SqlKind.
The biggest issue with it is that "SqlKind.IN" would *still* be around but it
would just mean nothing...its unfortunate that SqlKind contains the union of
the Kind-s of 2 worlds
but I don't think that something like "RexKind" would be a better taken on
this; I will keep thinking on this one - I think that some of the [inner
classes which are already inside
RexSimplify|https://github.com/apache/calcite/blob/2102f1f5442fa271c258b7754da8df07d65847ec/core/src/main/java/org/apache/calcite/rex/RexSimplify.java#L1911]
could make it better to work with RexNode-s; in this world then symmetric
property of the operator could me marked with an interface/annotation or
something
Right now I would prefer to go by fixing the field to be named correctly about
symmetrical ones.
> Computing digest of IN expressions leads to Exceptions
> ------------------------------------------------------
>
> Key: CALCITE-2842
> URL: https://issues.apache.org/jira/browse/CALCITE-2842
> Project: Calcite
> Issue Type: Bug
> Reporter: Zoltan Haindrich
> Assignee: Julian Hyde
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Testcase:
> {code}
> /* RexProgramTest */
> @Test public void testInDigest() {
> RexNode e = in(vInt(), literal(1), literal(2));
> assertThat(e.toString(), is("IN(?0.int0, 1, 2)"));
> }
> /* RexProgramBuilder */
> protected RexNode in(Iterable<? extends RexNode> nodes) {
> return rexBuilder.makeCall(SqlStdOperatorTable.IN,
> ImmutableList.copyOf(nodes));
> }
> {code}
> The exception is due to that it tries to look at the other operand
> https://github.com/apache/calcite/blob/883666929478aabe07ee5b9e572c43a6f1a703e2/core/src/main/java/org/apache/calcite/rex/RexCall.java#L115
> [SIMPLE_BINARY_OPS|https://github.com/apache/calcite/blob/883666929478aabe07ee5b9e572c43a6f1a703e2/core/src/main/java/org/apache/calcite/rex/RexCall.java#L64]
> contains
> [COMPARISION|https://github.com/apache/calcite/blob/883666929478aabe07ee5b9e572c43a6f1a703e2/core/src/main/java/org/apache/calcite/sql/SqlKind.java#L1248]
> which also contains "IN"
> this was introduced in CALCITE-2454 a few days ago; bug not released
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
