[
https://issues.apache.org/jira/browse/HIVE-10728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568227#comment-14568227
]
Ashutosh Chauhan edited comment on HIVE-10728 at 6/1/15 11:39 PM:
------------------------------------------------------------------
This is change in behavior of existing functionality. e.g, {{where c1 >
unix_timestamp()}} will give you different resultset depending on values of c1,
before and after this patch on same table.
I want to hear other committer's comment whether this is kosher to do this or
not. [~alangates] What do you think?
At the very least, this seems to fall into the category of something you want
to commit on trunk and not on branch-1.
was (Author: ashutoshc):
This is change in behavior of existing functionality. e.g, {{where c1 >
unix_timestamp() }} will give you different resultset depending on values of
c1, before and after this patch on same table.
I want to hear other committer's comment whether this is kosher to do this or
not. [~alangates] What do you think?
At the very least, this seems to fall into the category of something you want
to commit on trunk and not on branch-1.
> deprecate unix_timestamp(void) and make it deterministic
> --------------------------------------------------------
>
> Key: HIVE-10728
> URL: https://issues.apache.org/jira/browse/HIVE-10728
> Project: Hive
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Attachments: HIVE-10728.01.patch, HIVE-10728.02.patch,
> HIVE-10728.03.patch, HIVE-10728.patch
>
>
> We have a proper current_timestamp function that is not evaluated at runtime.
> Behavior of unix_timestamp(void) is both surprising, and is preventing some
> optimizations on the other overload since the function becomes
> non-deterministic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
