[ https://issues.apache.org/jira/browse/DRILL-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Volodymyr Vysotskyi resolved DRILL-3909. ---------------------------------------- Resolution: Fixed Fixed in the scope of DRILL-6094 > 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 > Assignee: Volodymyr Vysotskyi > Priority: Major > Fix For: Future > > > 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 (v7.6.3#76005)