Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
Impala 3.0
-
None
-
None
-
ghx-label-3
Description
Consider the following SQL:
SELECT CAST(257 AS TINYINT) AS c FROM functional.alltypestiny
Run this in the shell:
+----------------------+ | cast(257 as tinyint) | +----------------------+ | 1 | +----------------------+
The SQL-2016 standard, section 4.4 states:
If an assignment of some number would result in a loss of its most significant digit, an exception condition is raised.
Expected an error rather than wrong result.
This is not as simple as it appears. The BE is written in C which does not detect integer overflow. So, one could argue that the behavior is correct: Impala makes no guarantees about integer overflow.
On the other hand, the math above is actually done in the planner; the serialized plan contains an incorrect value. One could argue that the planner should be more strict than the runtime, so that this is an error.
Attachments
Issue Links
- Is contained by
-
IMPALA-7902 Revise NumericLiteral to avoid analysis, fix multiple issues
- Resolved
- relates to
-
IMPALA-6072 Uncaught overflow when multiplying two bigints
- Open