[
https://issues.apache.org/jira/browse/PHOENIX-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14257191#comment-14257191
]
Gabriel Reid commented on PHOENIX-1553:
---------------------------------------
[~jamestaylor], I'll check with you first of course :-) Do you have a clear
idea of how this "should" work in Phoenix right now?
> Casting between types is inconsistent
> -------------------------------------
>
> Key: PHOENIX-1553
> URL: https://issues.apache.org/jira/browse/PHOENIX-1553
> Project: Phoenix
> Issue Type: Bug
> Reporter: Gabriel Reid
>
> Casting values between types is currently not entirely clear or consistent.
> Some of the behavior is a clear bug, and in other places it's questionable.
> The most generic example of such behavior is when casting from a binary value
> into a numerical value. For example, the following upsert into an
> unsigned_tinyint:
> {code}
> UPSERT INTO MYTAB (unsigned_tinyint_id) values (CAST(MD5('ABC') AS TINYINT));
> {code}
> will work without error, and (correctly?) create a row key that contains the
> leading byte of the result of the {{MD5}} function.
> On the other hand, the following upsert into a signed tinyint:
> {code}
> UPSERT INTO MYTAB (unsigned_tinyint_id) values (CAST(MD5('ABC') AS TINYINT));
> {code}
> will run without issues, but it will use the full 16 bytes returned by the
> {{MD5}} function as the row key. In other words, it creates a corrupt record
> (which can still be queried in most cases).
> This same behavior is present for (at least) other numerical types as well.
> Assuming that both of these upsert statements can be considered valid, then
> it's clear that there is an issue how the coercing of bytes occurs.
> On the other hand, it may be may correct to disallow either of these
> statements, i.e. only numerical types can be cast from one to the other, and
> no casts are allowed from a {{BINARY}} to a numerical type.
> This is related to the issue reported in PHOENIX-1227, but not quite the same.
> The output of this ticket should be both a general spec on how casting
> "should" work, as well as bringing the implementation in line with this spec.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
