[
https://issues.apache.org/jira/browse/HIVE-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552495#comment-13552495
]
Gunther Hagleitner commented on HIVE-2693:
------------------------------------------
Mark: Thanks for the clarification. I had misunderstood you earlier. I think
you do bring up an important point about controlling representation, however, I
think my point about best fixing this with an optional scoped decimal is still
valid.
The example of the poor C++ thrift developer eventually got me thinking: Why
would setting the scale in round even have any effect? We strip trailing zeros
internally from all decimals, so 0.00, 0E-99 should always come out as simply 0.
(I think we've talked about this before, we have to strip zeros, because
otherwise sorting, joins, group-bys etc would all internally distinguish by
value and scale instead of just value, which would be bad because we allow
mixed-scale input and any operation performed on decimals can change the scale.)
So given that, the reason you are seeing the sticky scale on "round()" is this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6480539
A bug in the JVM: stripTrailingZeros doesn't work for the number "0".
I've put a workaround for that bug in the code (simply storing BigDecimal.ZERO
when the value is "0") and that gives at least consistent behavior between
floor, ceiling and round, however that still does not allow you to control the
representation. For that (given that we have to strip internally), I still
suggest another jira that let's you define types that do specifically that.
It does also help the C++ coder: With this round(mycol, 2) would give you at
most 2 decimal digits (instead of potentially unlimited many). So if they init
that buffer right, they should be fine.
So can you take a look at patch 23? It only special-cases the ZERO value (and
removes the meaningless setting to original scale in round). Does that seem
reasonable?
> Add DECIMAL data type
> ---------------------
>
> Key: HIVE-2693
> URL: https://issues.apache.org/jira/browse/HIVE-2693
> Project: Hive
> Issue Type: New Feature
> Components: Query Processor, Types
> Affects Versions: 0.10.0
> Reporter: Carl Steinbach
> Assignee: Prasad Mujumdar
> Attachments: 2693_7.patch, 2693_8.patch, 2693_fix_all_tests1.patch,
> HIVE-2693-10.patch, HIVE-2693-11.patch, HIVE-2693-12-SortableSerDe.patch,
> HIVE-2693-13.patch, HIVE-2693-14.patch, HIVE-2693-15.patch,
> HIVE-2693-16.patch, HIVE-2693-17.patch, HIVE-2693-18.patch,
> HIVE-2693-19.patch, HIVE-2693-1.patch.txt, HIVE-2693-20.patch,
> HIVE-2693-21.patch, HIVE-2693-22.patch, HIVE-2693-all.patch,
> HIVE-2693.D7683.1.patch, HIVE-2693-fix.patch, HIVE-2693.patch,
> HIVE-2693-take3.patch, HIVE-2693-take4.patch
>
>
> Add support for the DECIMAL data type. HIVE-2272 (TIMESTAMP) provides a nice
> template for how to do this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
