You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Ruben Q L (Jira)" <ji...@apache.org> on 2020/11/20 17:31:00 UTC
[jira] [Updated] (CALCITE-4415) SqlStdOperatorTable.NOT_LIKE has a
wrong implementor
[ https://issues.apache.org/jira/browse/CALCITE-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ruben Q L updated CALCITE-4415:
-------------------------------
Description:
{{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}
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.
was:
{{SqlStdOperatorTable.NOT_LIKE}}'s implementor defined in {{RexImpTable}} is currently the same as {{LIKE}} (i.e. NOT_LIKE does the same as LIKE):
{code}
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.
> 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
> Priority: Major
> Fix For: 1.27.0
>
>
> {{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}
> 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)