Ádám Szita created HIVE-22513: --------------------------------- Summary: Constant propagation of casted column in filter ops can cause incorrect results Key: HIVE-22513 URL: https://issues.apache.org/jira/browse/HIVE-22513 Project: Hive Issue Type: Bug Reporter: Ádám Szita Assignee: Ádám Szita
This issue happens if CBO is disabled. We should not be propagating constants if the corresponding ExprNodeColumnDesc instance is wrapped inside a CAST operator as casting might truncate information from the original column. This can happen if we're using CAST in a WHERE clause, which will cause the projected columns to be replaced in a SELECT operator. Their new value will be the result of casting which could be a different value compared to that in the original column: {code:java} set hive.cbo.enable=false; set hive.fetch.task.conversion=more; --just for testing convenience create table testtb (id string); insert into testtb values('2019-11-05 01:01:11'); select id, CAST(id AS VARCHAR(10)) from testtb where CAST(id AS VARCHAR(9)) = '2019-11-0'; +------------+------------+ | id | _c1 | +------------+------------+ | 2019-11-0 | 2019-11-0 | +------------+------------+ 1 row selected (0.168 seconds) -- VS expected: 2019-11-05 01:01:11 | 2019-11-05 {code} As to what types of casting (from and where types) cause information loss it's hard to properly keep track of, and I don't think it should be taken into consideration when deciding whether or not to propagate a constant. Rather than adding a big and potentially convoluted and fragile check for this, I propose to prevent constant mappings to be spawned out of CASTed columns. -- This message was sent by Atlassian Jira (v8.3.4#803005)