[jira] [Created] (DRILL-3909) Decimal round functions corrupts input data

["Steven Phillips (JIRA)" <ji...@apache.org>]

Steven Phillips created DRILL-3909:
--------------------------------------

             Summary: Decimal round functions corrupts input data
                 Key: DRILL-3909
                 URL: https://issues.apache.org/jira/browse/DRILL-3909
             Project: Apache Drill
          Issue Type: Bug
            Reporter: Steven Phillips
             Fix For: 1.3.0


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:
{code}
$ 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  |
+-----------------------+----------------+
{code}

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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)