[
https://issues.apache.org/jira/browse/CALCITE-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-7811.
----------------------------------
Fix Version/s: 1.43.0
Resolution: Fixed
Fixed in
[03be771|https://github.com/apache/calcite/commit/03be7710ca4824c5051f0e9fff22ce80475b4c9a].
Thanks for the PR.
(By "slop", I meant the description of the proposed fix in one of the Jira
comments. In my opinion, a good description of the problem is sufficient; an
AI-generated description of the proposed fix is unnecessary if there is a PR
with the fix, unless the fix requires significant refactoring or changes in
architecture.)
> RexImplicationChecker incorrectly proves NOT(x = a) implies (x = a OR x = b)
> ----------------------------------------------------------------------------
>
> Key: CALCITE-7811
> URL: https://issues.apache.org/jira/browse/CALCITE-7811
> Project: Calcite
> Issue Type: Bug
> Reporter: Jasmin Trada
> Assignee: Jasmin Trada
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.43.0
>
>
> RexImplicationChecker.implies() can return true for an implication that does
> not
> actually hold, when the premise contains NOT wrapped directly around a
> comparison
> (e.g. NOT(x = a)).
> Repro:
> {code:java}
> final Fixture f = new Fixture();
> final RexNode sEqA = f.eq(f.str, f.charLiteral("a"));
> final RexNode sEqB = f.eq(f.str, f.charLiteral("b"));
> final RexNode sNeA = f.ne(f.str, f.charLiteral("a"));
> final RexNode sNotEqA = f.rexBuilder.makeCall(SqlStdOperatorTable.NOT, sEqA);
> final RexNode sEqAOrEqB = f.or(sEqA, sEqB);
> // Correct: the checker soundly declines to prove this (x = 'c' is a
> counterexample).
> assertFalse(f.checker.implies(sNeA, sEqAOrEqB));
> // Bug: the logically identical NOT(x = 'a') is wrongly reported as implying
> the OR.
> assertTrue(f.checker.implies(sNotEqA, sEqAOrEqB)); // should be false
> {code}
> "x <> 'a'" and "NOT(x = 'a')" are logically identical, but the checker treats
> them
> differently: only the syntactic NOT_EQUALS form is handled soundly. NOT(x =
> 'a')
> is silently misrecorded internally as a plain x = 'a' usage, so the checker
> "proves"
> NOT(x = 'a') implies (x = 'a' OR x = 'b') by testing x = 'a' against the
> right-hand
> side, instead of testing x <> 'a'.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
