Á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)
