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

Jason Dere commented on HIVE-5356:
----------------------------------

Nice.  I was playing with the patch and had some questions about the return 
typeInfo when using decimal with non-decimals:

{noformat}
hive> explain select cast(1 as decimal(10,2)) / cast(1 as decimal(10,2))  from 
src;
...
              expressions:
                    expr: (CAST( 1 AS decimal(10,2)) / CAST( 1 AS 
decimal(10,2)))
                    type: decimal(23,13)
{noformat}

Ok so far.

{noformat}
hive> explain select cast(1 as decimal(10,2)) / cast(1 as decimal(10,2)) /2 
from src;
...
              expressions:
                    expr: ((CAST( 1 AS decimal(10,2)) / CAST( 1 AS 
decimal(10,2))) / 2)
                    type: double
{noformat}

Maybe we can keep the result type as decimal when possible? At least when the 
other argument is also exact numeric (int, short, etc). 

> Move arithmatic UDFs to generic UDF implementations
> ---------------------------------------------------
>
>                 Key: HIVE-5356
>                 URL: https://issues.apache.org/jira/browse/HIVE-5356
>             Project: Hive
>          Issue Type: Task
>          Components: UDF
>    Affects Versions: 0.11.0
>            Reporter: Xuefu Zhang
>            Assignee: Xuefu Zhang
>             Fix For: 0.13.0
>
>         Attachments: HIVE-5356.patch
>
>
> Currently, all of the arithmetic operators, such as add/sub/mult/div, are 
> implemented as old-style UDFs and java reflection is used to determine the 
> return type TypeInfos/ObjectInspectors, based on the return type of the 
> evaluate() method chosen for the expression. This works fine for types that 
> don't have type params.
> Hive decimal type participates in these operations just like int or double. 
> Different from double or int, however, decimal has precision and scale, which 
> cannot be determined by just looking at the return type (decimal) of the UDF 
> evaluate() method, even though the operands have certain precision/scale. 
> With the default of "decimal" without precision/scale, then (10, 0) will be 
> the type params. This is certainly not desirable.
> To solve this problem, all of the arithmetic operators would need to be 
> implemented as GenericUDFs, which allow returning ObjectInspector during the 
> initialize() method. The object inspectors returned can carry type params, 
> from which the "exact" return type can be determined.
> It's worth mentioning that, for user UDF implemented in non-generic way, if 
> the return type of the chosen evaluate() method is decimal, the return type 
> actually has (10,0) as precision/scale, which might not be desirable. This 
> needs to be documented.
> This JIRA will cover minus, plus, divide, multiply, mod, and pmod, to limit 
> the scope of review. The remaining ones will be covered under HIVE-5706.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Reply via email to