Gabriel Reid created PHOENIX-1553:
-------------------------------------
Summary: 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)
