[
https://issues.apache.org/jira/browse/HIVE-22513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978334#comment-16978334
]
Hive QA commented on HIVE-22513:
--------------------------------
Here are the results of testing the latest attachment:
https://issues.apache.org/jira/secure/attachment/12986315/HIVE-22513.1.patch
{color:green}SUCCESS:{color} +1 due to 1 test(s) being added or modified.
{color:green}SUCCESS:{color} +1 due to 17708 tests passed
Test results:
https://builds.apache.org/job/PreCommit-HIVE-Build/19508/testReport
Console output: https://builds.apache.org/job/PreCommit-HIVE-Build/19508/console
Test logs: http://104.198.109.242/logs/PreCommit-HIVE-Build-19508/
Messages:
{noformat}
Executing org.apache.hive.ptest.execution.TestCheckPhase
Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.YetusPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase
{noformat}
This message is automatically generated.
ATTACHMENT ID: 12986315 - PreCommit-HIVE-Build
> 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
> Priority: Major
> Attachments: HIVE-22513.0.patch, HIVE-22513.1.patch
>
>
> 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)
