[
https://issues.apache.org/jira/browse/PHOENIX-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14257350#comment-14257350
]
James Taylor commented on PHOENIX-1553:
---------------------------------------
I think we should follow the SQL standards here. It is useful, though, to be
able to cast from BINARY to another stronger type. For example, you may have a
more a use case where you store the data as VARBINARY and then use some
external means to cast it to the correct type in a kind of polymorphic way.
bq. In other words, it creates a corrupt record (which can still be queried in
most cases).
Clearly this is a bug. A cast from a bigger to smaller type should error out if
it can't fit in the smaller type.
> 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)
