You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unexpected result when using string comparison ANDIS NULL #15395
Consider the test cases below. It is unexpected that the third query returns empty result, since the second query returns TRUE, which means that the WHERE clause in the third query should be evaluated to TRUE and thus return the row in the table.
Steps to Reproduce
DROPTABLE IF EXISTS t1;
CREATETABLEt1(c0 VARCHAR, PRIMARY KEY(c0));
INSERT INTO t1 (c0) VALUES ('a');
REFRESH TABLE t1;
SELECT*FROM t1; -- 'a'SELECT NOT ((t1.c0!='1' )AND (t1.c0 IS NULL)) FROM t1; -- TRUESELECT*FROM t1 WHERE NOT ((t1.c0!='1' )AND (t1.c0 IS NULL));
-- Expected: 'a'-- Actual: empty result
SELECT * FROM t1 WHERE NOT ((t1.c0 != '1' )AND (t1.c0 IS NULL)); is equivalent to SELECT * FROM t1 WHERE NOT (t1.c0 IS NULL); but the former uses get (invalid optimization from collect attempting to utilize the primary key in the where clause) while latter uses collect operator:
cr> EXPLAIN SELECT * FROM t1 WHERE NOT ((t1.c0 != '1' )AND (t1.c0 IS NULL));
+--------------------------------------------------------------------------------------+
| QUERY PLAN |
+--------------------------------------------------------------------------------------+
| Get[doc.t1 | c0 | DocKeys{'1'} | (NOT ((NOT (c0 = '1')) AND (c0 IS NULL)))] (rows=1) |
+--------------------------------------------------------------------------------------+
cr> EXPLAIN SELECT * FROM t1 WHERE NOT ((t1.c0 IS NULL));
+------------------------------------------------------------+
| QUERY PLAN |
+------------------------------------------------------------+
| Collect[doc.t1 | [c0] | (NOT (c0 IS NULL))] (rows=unknown) |
+------------------------------------------------------------+
The fix causes issues with outer joins and it's being reverted with: #15468
Thank you for handling the revert @matriv. For the outer join scenario, the arg to is null was actually core.users_roles.user_id which I think could been some kind of a ScopedSymbol(or AliasSymbol?) such that it would be prevented from is null normalization. WDYT? If sounds feasible, this could be something to look into during feature freeze.
Thank you for handling the revert @matriv. For the outer join scenario, the arg to is null was actually core.users_roles.user_id which I think could been some kind of a ScopedSymbol(or AliasSymbol?) such that it would be prevented from is null normalization. WDYT? If sounds feasible, this could be something to look into during feature freeze.
We should not optimize/normalize the is null/is not null of a where clause, when it acts on a column of the table on the "outer" side of the join, I don't think AliasSymbol or so is enough to catch that.
Activity
matriv commentedon Jan 18, 2024
Also exists in
5.5.2.jeeminso commentedon Jan 19, 2024
Thanks a lot for reporting, @suyZhong!
SELECT * FROM t1 WHERE NOT ((t1.c0 != '1' )AND (t1.c0 IS NULL));is equivalent toSELECT * FROM t1 WHERE NOT (t1.c0 IS NULL);but the former usesget(invalid optimization fromcollectattempting to utilize the primary key in thewhereclause) while latter usescollectoperator:jeeminso commentedon Jan 25, 2024
Thanks again for reporting @suyZhong , this is fixed by #15401.
matriv commentedon Jan 29, 2024
The fix causes issues with outer joins and it's being reverted with: #15468
jeeminso commentedon Jan 29, 2024
Thank you for handling the revert @matriv. For the outer join scenario, the arg to
is nullwas actuallycore.users_roles.user_idwhich I think could been some kind of aScopedSymbol(orAliasSymbol?) such that it would be prevented fromis nullnormalization. WDYT? If sounds feasible, this could be something to look into during feature freeze.matriv commentedon Jan 29, 2024
We should not optimize/normalize the
is null/is not nullof a where clause, when it acts on a column of the table on the "outer" side of the join, I don't thinkAliasSymbolor so is enough to catch that.jeeminso commentedon Feb 1, 2024
Fixed by #15487.