[
https://issues.apache.org/jira/browse/HIVE-20204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16548324#comment-16548324
]
Jason Dere commented on HIVE-20204:
-----------------------------------
Looks like the following can be removed from ReturnObjectInspectorResolver,
since HIVE-13380 has addressed this.
{code}
protected static TypeInfo updateCommonTypeForDecimal(
TypeInfo commonTypeInfo, TypeInfo ti, TypeInfo returnType) {
/**
* TODO: Hack fix until HIVE-5848 is addressed. non-exact type shouldn't be
promoted
* to exact type, as FunctionRegistry.getCommonClass() might do. This
corrects
* that.
*/
{code}
> Type conversion during IN () comparisons is using different rules from other
> comparison operations
> --------------------------------------------------------------------------------------------------
>
> Key: HIVE-20204
> URL: https://issues.apache.org/jira/browse/HIVE-20204
> Project: Hive
> Issue Type: Bug
> Components: Types
> Reporter: Jason Dere
> Assignee: Jason Dere
> Priority: Major
>
> Noticed this while looking at HIVE-20082.
> The type conversion done during GenericUDFIn (via
> ReturnObjectInspectorResolver) uses FunctionRegistry.getCommonClass(),
> whereas the other comparison operators (=, <, >, <=, >=) use
> FunctionRegistry.getCommonClassForComparison(). As a result, dec_column IN
> ('1.1', '2.2') compares the values as strings, whereas dec_column = '1.1'
> would compare the values as doubles. This makes a difference for HIVE-20082
> since it is related to changing the 0-padding during decimal-to-string
> conversions.
> cc [~ashutoshc]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
