[
https://issues.apache.org/jira/browse/CALCITE-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236810#comment-17236810
]
Julian Hyde commented on CALCITE-4415:
--------------------------------------
How can I persuade you of the benefits of keeping the Rex language minimal?
There are many operators that are supported in Sql-land but not Rex-land. In my
opinion, NOT_LIKE and NOT_SIMILAR_TO should be in that category.
It may be one line for you, but there are many other lines of code that will
need to be written to fully support NOT_LIKE in Rex land. Note that there are
13 uses of the LIKE operator but only 7 uses of NOT_LIKE.
There is no SqlKind.NOT_LIKE. There are several pieces of code that checks for
RexNode.getKind() == SqlKind.LIKE and does not check whether it is a call to
LIKE or NOT_LIKE operator.
I suggest that you remove that line of code from the implementor, make
RelBuilder translate NOT_LIKE(...) to NOT(LIKE ...), and override
validateRexOperands in SqlLikeOperator to prevent people from creating RexCalls
to NOT_LIKE. Also remove some wrong code (unused, fortunately) in
PredicateAnalyzer of the Elasticsearch adapter.
> SqlStdOperatorTable.NOT_LIKE has a wrong implementor
> ----------------------------------------------------
>
> Key: CALCITE-4415
> URL: https://issues.apache.org/jira/browse/CALCITE-4415
> Project: Calcite
> Issue Type: Bug
> Reporter: Ruben Q L
> Assignee: Ruben Q L
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{SqlStdOperatorTable.NOT_LIKE}}'s implementor defined in {{RexImpTable}} is
> currently the same as {{LIKE}} (i.e. {{NOT_LIKE}} performs the same operation
> as {{LIKE}}):
> {code}
> ...
> final MethodImplementor likeImplementor =
> new MethodImplementor(BuiltInMethod.LIKE.method, NullPolicy.STRICT,
> false);
> map.put(LIKE, likeImplementor);
> map.put(NOT_LIKE, likeImplementor);
> {code}
> It should be:
> {code}
> ...
> map.put(LIKE, likeImplementor);
> map.put(NOT_LIKE, NotImplementor.of(likeImplementor));
> {code}
> Luckily, SQL queries seem to not suffer the consequences because
> {{StandardConvertletTable}} expands {{x NOT LIKE y}} into {{NOT (x LIKE y)}},
> so the issue is avoided:
> {code}
> // Expand "x NOT LIKE y" into "NOT (x LIKE y)"
> registerOp(SqlStdOperatorTable.NOT_LIKE,
> (cx, call) -> cx.convertExpression(
> SqlStdOperatorTable.NOT.createCall(SqlParserPos.ZERO,
> SqlStdOperatorTable.LIKE.createCall(SqlParserPos.ZERO,
> call.getOperandList()))));
> {code}
> However, creating a plan via RelBuilder using
> {{SqlStdOperatorTable.NOT_LIKE}} will lead to incorrect results.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
