Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
1.4.2
-
None
-
2020-2, 2020-5
Description
Below is the reproduction, now in 3787. The commit made for this ticket does not fix the issue, only cleans up some code.
********************************************************************
Consider the example:
CREATE TABLE cs1 (a BIGINT)engine=columnstore;
|
INSERT INTO cs1 VALUES (42);
|
MariaDB [test]> select sum(a) from cs1 having -1 != -1;
|
+--------+
|
| sum(a) |
|
+--------+
|
| NULL |
|
+--------+
|
1 row in set, 1 warning (0.012 sec)
|
 |
CREATE TABLE t1 (a BIGINT);
|
INSERT INTO t1 VALUES (42);
|
MariaDB [test]> select sum(a) from t1 having 1 != 1;
|
Empty set (0.001 sec)
|
create_SH checks whether HAVING or WHERE has impossible conditions returning if there are such. After JOIN::optimize() had been removed from create_SH thus both select_lex->having_value, select_lex->cond_value always are in COND_UNDEF. This disables the check.
There are two ways:
- reuse the code and port Item_cond::remove_eq_conds and all prerequisites to reenable check in create_SH
- implement custom Item traverser that searches for a conditions that is constant column with a value of 0.
Attachments
Issue Links
- relates to
-
MCOL-3787 CS doesn't apply having with impossible condition on top of aggregation
- Closed