[
https://issues.apache.org/jira/browse/HIVE-17103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16092204#comment-16092204
]
Ashutosh Chauhan commented on HIVE-17103:
-----------------------------------------
I think decision of not doing implicit conversion across different type groups
is sound.
I tried union for combination of varchar/date and varchar/int in oracle and pg
and both failed. So, hive is consistent in its behavior with other systems.
oracle [1] and postgres[2] have it documented
[1] https://www.postgresql.org/docs/9.0/static/typeconv-union-case.html -
Bullet point 4.
[2] https://docs.oracle.com/cd/B19306_01/server.102/b14200/queries004.htm -
just before examples section.
> HIVE-14251 severely impacts backward compatibility of UNION ALL queries
> -----------------------------------------------------------------------
>
> Key: HIVE-17103
> URL: https://issues.apache.org/jira/browse/HIVE-17103
> Project: Hive
> Issue Type: Bug
> Components: Types
> Affects Versions: 2.2.0
> Reporter: Jason Dere
>
> HIVE-14251 looks like it changed behavior of type conversion during UNION ALL
> queries, where types that are of different primitive groups (date, string,
> numeric, binary, boolean) cannot be unioned together with implicit
> conversions, and requires an explicit type cast to the desired type.
> That HIVE-14251 breaks backward compatibility is spelled out in the release
> notes. However I'm wondering if this was the right fix - this has quite a big
> impact on the usability of UNION ALL.
> Some alternative suggestions:
> 1. Should we have simply not fixed HIVE-14251? While almost all DBMSs
> recommend users to use explicit casts, a lot of people just rely on implicit
> casting (if supported), and then do explicit casting if they want something
> other than the default behavior. This might have been one of the times the
> user would want to use explicit casts to override the default Hive behavior.
> 2. Try to specifically fix the case for HIVE-14251 (union behavior of date,
> numeric). I was actually surprised union of date and numeric values worked,
> because when I originally did DATE type I tried to make sure DATE was not
> convertible to anything except string/timestamp. For example I don't think
> you can actually explicitly cast DATE to INT. We could try to make this
> particular implicit union conversion invalid (as well as any others we feel
> may not ).
> cc [~aihuaxu] [~mohitsabharwal] [~ctang.ma] [~ashutoshc] [~aravindgopal]
> [~sershe] as these are the names I've seen on HIVE-14251, as well as related
> Jira HIVE-16050
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
