[
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)
