Github user daveoshinsky commented on the issue:
https://github.com/apache/drill/pull/517
Paul, do you mean the long piece of code with conditions on various
destination precision types, that sets inPrec and maxPrec, and then selects the
smaller of the two for the resulting precision? Â I think it's just way simpler
to use the calculated precision, as I suggested earlier. Â That also works, and
it's less code to look at, and less code to potentially be broken. Â I do have
a bias against the heavy, heavy use of FreeMarker everywhere. Â It's just a
recipe for bugs piled on top of bugs, and all of the numerous FreeMarker
conditions are not likely to be tested for quite some time.
On Monday, August 8, 2016 1:48 PM, Paul Rogers
<[email protected]> wrote:
What is the resolution here? Dave, do you want to review & adopt the
suggested code several posts back? That code passed the unit tests that you
provided, plus those aready in Drill (using the unit tests you suggested in an
earlier post.) Then, update this PR with the results. Sounds like Jinfeng can
then review the code & accept the PR. As we've said, the fix is not perfect,
but it does work for every int/decimal type if the user is careful to provide
int values that fit within the target decimal type.â
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
