[
https://issues.apache.org/jira/browse/HIVE-13963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319735#comment-15319735
]
Sergey Shelukhin commented on HIVE-13963:
-----------------------------------------
[~xuefuz] see the new Q file added in HIVE-13957. Before the fix there (that
disables vectorization for IN for such cases), the vectorized query returns no
results.
The code in vectorization that adds casts to arguments (before evaluating them)
for UDFs like IN, and gets precision and scale for the cast depending on the
type, is the problem.
> vectorization - string arguments may be converted to decimal null
> -----------------------------------------------------------------
>
> Key: HIVE-13963
> URL: https://issues.apache.org/jira/browse/HIVE-13963
> Project: Hive
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Assignee: Matt McCline
> Priority: Critical
>
> See HIVE-13957.
> The default precision and scale for the implicit decimal cast are max,max, ie
> 38,38. Those don't do what the code may assume they do. All the values > 0
> become invalid and precision-scale enforcement automatically converts them to
> null.
> We need to
> 1) Validate when this happens in/after the conversion code and bail;
> 2) Or, derive precision and scale from the constants themselves so they all
> fit, instead;
> 3) Or, derive it from the type of whatever caused the conversion in the first
> place (e.g. IN column decimal); however, this could be function-specific
> (e.g. IN just needs equality, BETWEEN would need at least one extra digit,
> arithmetic, if this ever happens, would need everything, etc.);
> 4) Something else? :)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
