[ 
https://issues.apache.org/jira/browse/HIVE-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757325#comment-13757325
 ] 

Jason Dere commented on HIVE-5203:
----------------------------------

I have a test case in the main varchar patch, but it won't work here since that 
type doesn't exist yet. Unfortunately with the compatibility behavior between 
the existing types, I don't think we can actually hit a situation where we'll 
run into this issue with the current types.  The closest we'd be able to get 
would be if Date and Timestamp were implicitly convertable to one another, and 
they are not. Otherwise, the best we can do at the moment is testing that the 
existing tests in TestFunctionRegistry still work fine.
                
> FunctionRegistry.getMethodInternal() should prefer method arguments with 
> closer affinity to the original argument types
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: HIVE-5203
>                 URL: https://issues.apache.org/jira/browse/HIVE-5203
>             Project: Hive
>          Issue Type: Bug
>          Components: Types, UDF
>            Reporter: Jason Dere
>            Assignee: Jason Dere
>         Attachments: HIVE-5203.1.patch
>
>
> When the function registry is trying to determine the best version of UDF 
> evaluate() to use based on a set of arguments passed in, it should prefer 
> methods where the argument types are more related to the original types. For 
> example if varchar is used with UDFFromUnixTime(), varchar is convertible to 
> both the double and string versions of evaluate() for that UDF.  In this case 
> we would prefer that the function registry select the string version over the 
> double version, since varchar and string are both string types.
> This doesn't really affect any of the existing types, but comes into play 
> with the addition of the varchar type (HIVE-4844).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to