[
https://issues.apache.org/jira/browse/CALCITE-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237680#comment-17237680
]
Julian Hyde commented on CALCITE-4415:
--------------------------------------
If we follow the principle that the Rex language should be minimal (or close to
minimal), then NOT_LIKE should not exist in Rex land. So, your quick test shows
up a violation of that principle.
I personally believe in that principle. I have noticed that if you let people
use an operator in one place (e.g. {{RelToSqlConverter}}) then they will use it
in other places (e.g. the Elasticsearch adapter). Because {{SqlToRelConverter}}
is not creating {{NOT_LIKE}} calls, we end up in the worst of all worlds:
{{NOT_LIKE}} is being used but is not being adequately tested.
If you buy into the principle, then there is tech debt, and your change is
increasing the tech debt. I'd rather not increase tech debt, even for a day, by
committing a one line change.
Do you have a partial PR that tries to remove NOT_LIKE from the Rex language? I
am happy to take it over from you, and finish the job. Let me know.
> 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)
