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)