hadoop-hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ashish Thusoo (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HIVE-65) Implict conversion from integer to long broken for Dynamic Serde tables
Date Thu, 04 Dec 2008 03:56:46 GMT

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

Ashish Thusoo commented on HIVE-65:
-----------------------------------

Description of implicit conversions in PL/SQL

http://www-camden.rutgers.edu/HELP/Documentation/Oracle/server.815/a67842/02_funds.htm#3435

Description of implicit conversion in Postgres

http://www.postgresql.org/docs/7.3/static/typeconv.html

In light of this and the mysql implicit conversion for comparison types

I think fundamentally the model is as follows:

1. For overloaded comparison operators (>,<, >=, <=, <>, =):
      If both the operands have the same type, then we have an exact match
      otherwise, If one of the operands is a date and the other is not, then convert the other
to a date.
      otherwise, If the two arguments are not of the same type, convert them both to double
and do the comparison.
      Note that we do not do this for LIKE, RLIKE and REGEXP as those operators are not overloaded
and every type is convertible to string

2. For overloaded arithmetic operators (+, -, *, /, %, &, |, ^):
      If both the operands have the same types then we have an exact match
      otherwise we convert everything to double
      In this case the logical operators will just work as is as they are not overloaded in
the sense that they do not have multiple evaluate functions.

We allow seemless conversions within numbers, from string to numbers and vice versa as well
as from date to string and vice versa. We may allow seemless conversion between date and int
at some point (once we support date more formally)

When looking for a match in a generic overloaded function (which is user defined and not one
of the cases enumerated above as we have already addressed those), we use the current mechanism
of picking up an evaluate function that needs
least number of conversions, otherwise we throw an ambiguity.

So instead of encoding hierarchies, in the UDFTo... classes we will encode the conversion
rules and then use the above to figure out the matches.

I think this will give us the same results as mysql and other DBs as well.

One thing that is still not very clean in this is the bit operators...

I think this somewhat addresses all the concerns except the storage one which Joy raised,
but even Oracle there warns about the same issue and asks the user to casting properly. These
set of rules are also hopefully much simpler to code and to explain to the users.

Thoughts? 

> Implict conversion from integer to long broken for Dynamic Serde tables
> -----------------------------------------------------------------------
>
>                 Key: HIVE-65
>                 URL: https://issues.apache.org/jira/browse/HIVE-65
>             Project: Hadoop Hive
>          Issue Type: Bug
>          Components: Query Processor
>            Reporter: Ashish Thusoo
>            Assignee: Zheng Shao
>
> For a dynamic serde table that has a bigint column, implict conversion from int to bigint
seems to be broken. I have not verified this for other tables.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message