[
https://issues.apache.org/jira/browse/HIVE-9917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14393764#comment-14393764
]
Jason Dere commented on HIVE-9917:
----------------------------------
So this is covering the case of converting an int to timestamp where there is
an actual cast operator being used, either explicitly in the query or
implicitly added to the query (such as when inserting integer values into a
timestamp column in a table). Not sure if there are any cases where Hive is
implicitly doing the conversion of int to timestamp without an actual cast
operator, I guess you can look at the callers of
PrimitiveObjectInpsectors.getTimestamp(). Looking at that, it looks like the
Hive-HBase interaction converts timestamps to/from long values based on millis
since epoch, so might want to confirm it's still doing the right thing here.
It's calling getTimestamp() with the old method signature (without the config
param), so I guess that means it is doing the conversion based on the old
behavior, which I think is correct?
Do we have to worry about conversions going the other way - from Timestamp to
int/long? Did that always convert to integer based on seconds, and it was just
the int to timestamp conversion that was inconsistent?
Will defer to [~mmccline] on the vectorization-related changes, though they
seem ok. Are there any times where vectorization does implicit conversion
without using the cast operator?
> After HIVE-3454 is done, make int to timestamp conversion configurable
> ----------------------------------------------------------------------
>
> Key: HIVE-9917
> URL: https://issues.apache.org/jira/browse/HIVE-9917
> Project: Hive
> Issue Type: Improvement
> Reporter: Aihua Xu
> Assignee: Aihua Xu
> Attachments: HIVE-9917.patch
>
>
> After HIVE-3454 is fixed, we will have correct behavior of converting int to
> timestamp. While the customers are using such incorrect behavior for so long,
> better to make it configurable so that in one release, it will default to
> old/inconsistent way and the next release will default to new/consistent way.
> And then we will deprecate it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
