Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
The Decimal 28 and 38 round functions, instead of creating a new buffer and copying data from the incoming buffer, set the output buffer equal to the input buffer, and then subsequently mutate the data in that buffer. This causes the data in the input buffer to be corrupted.
A simple example to reproduce:
$ cat a.json
{ a : "999999999.9999999995678" }
0: jdbc:drill:drillbit=localhost> create table a as select cast(a as decimal(38,18)) a from `a.json`;
+-----------+----------------------------+
| Fragment | Number of records written |
+-----------+----------------------------+
| 0_0 | 1 |
+-----------+----------------------------+
1 row selected (0.206 seconds)
0: jdbc:drill:drillbit=localhost> select round(a, 9) from a;
+-----------------------+
| EXPR$0 |
+-----------------------+
| 1000000000.000000000 |
+-----------------------+
1 row selected (0.121 seconds)
0: jdbc:drill:drillbit=localhost> select round(a, 11) from a;
+------------------------+
| EXPR$0 |
+------------------------+
| 999999999.99999999957 |
+------------------------+
1 row selected (0.115 seconds)
0: jdbc:drill:drillbit=localhost> select round(a, 9), round(a, 11) from a;
+-----------------------+----------------+
| EXPR$0 | EXPR$1 |
+-----------------------+----------------+
| 1000000000.000000000 | 1.00000000000 |
+-----------------------+----------------+
In the third example, there are two round expressions operating on the same incoming decimal vector, and you can see that the result for the second expression is incorrect.
Not critical because Decimal type is considered alpha right now.
Attachments
Issue Links
- relates to
-
DRILL-6094 Decimal data type enhancements
-
- Closed
-