[
https://issues.apache.org/jira/browse/HIVE-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193245#comment-13193245
]
Phabricator commented on HIVE-2249:
-----------------------------------
zhiqiu has commented on the revision "HIVE-2249 [jira] When creating constant
expression for numbers, try to infer type from another comparison operand,
instead of trying to use integer first, and then long and double".
Thanks a lot, Kevin! I'll remove the un-used lines.
Just tried to update insert2_overwrite_partitions.q and
insert1_overwrite_partitions.q to add "order by" clause.
For ppr_pushdown, I think you analyses also apply. It failed on my side b/c
the query like this:
select * from ppr_test where ds = '1234'
The results on my machine are:
1234 1234
abcd 1234
while the "expected" outputs are:
abcd 1234
1234 1234
So I think it is good to also add "order by" to this case, right?
REVISION DETAIL
https://reviews.facebook.net/D1383
> When creating constant expression for numbers, try to infer type from another
> comparison operand, instead of trying to use integer first, and then long and
> double
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HIVE-2249
> URL: https://issues.apache.org/jira/browse/HIVE-2249
> Project: Hive
> Issue Type: Improvement
> Reporter: Siying Dong
> Assignee: Joseph Barillari
> Attachments: HIVE-2249.1.patch.txt, HIVE-2249.2.patch.txt,
> HIVE-2249.D1383.1.patch
>
>
> The current code to build constant expression for numbers, here is the code:
> try {
> v = Double.valueOf(expr.getText());
> v = Long.valueOf(expr.getText());
> v = Integer.valueOf(expr.getText());
> } catch (NumberFormatException e) {
> // do nothing here, we will throw an exception in the following block
> }
> if (v == null) {
> throw new SemanticException(ErrorMsg.INVALID_NUMERICAL_CONSTANT
> .getMsg(expr));
> }
> return new ExprNodeConstantDesc(v);
> The for the case that "WHERE <BIG_INT_COLUMN> = 0", or "WHERE <DOUBLE_COLUMN>
> = 0", we always have to do a type conversion when comparing, which is
> unnecessary if it is slightly smarter to choose type when creating the
> constant expression. We can simply walk one level up the tree, find another
> comparison party and use the same type with that one if it is possible. For
> user's wrong query like '<INT_COLUMN>=1.1', we can even do more.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
