[
https://issues.apache.org/jira/browse/CALCITE-2684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692845#comment-16692845
]
Ruben Quesada Lopez edited comment on CALCITE-2684 at 11/20/18 8:37 AM:
------------------------------------------------------------------------
Thanks for your feedback, [~julianhyde].
In the example that you describe, a BIGINT will be generated. The reason for
that is that the {{bd.unscaledValue().longValue()}} will overflow the long
range, therefore the first condition of the "if" will be false
{{(BigDecimal.valueOf(l, scale).equals(bd))}}.
{code:java}
...
long l = bd.unscaledValue().longValue();
if ((BigDecimal.valueOf(l, scale).equals(bd))
&& (l >= Integer.MIN_VALUE) && (l <= Integer.MAX_VALUE)) {
relType = typeFactory.createSqlType(SqlTypeName.INTEGER);
} else {
relType = typeFactory.createSqlType(SqlTypeName.BIGINT);
}
{code}
The logic that I'm trying to apply is that: check if {{l}} is in the integer
range (to generate an INTEGER) only if {{l}} is the "right long value", i.e. it
did not overflow, and in order to check that we verify if we can rebuild the
original BigDecimal parameter using {{l}} and {{scale}}. Otherwise, generate a
BIGINT.
was (Author: rubenql):
Thanks for your feedback, [~julianhyde].
In the example that you describe, a BIGINT will be generated. The reason for
that is that the {{bd.unscaledValue().longValue()}} will overflow the long
range, therefore the first condition of the "if" will be false
{{(BigDecimal.valueOf(l, scale).equals(bd))}}.
{code:java}
...
long l = bd.unscaledValue().longValue();
if ((BigDecimal.valueOf(l, scale).equals(bd))
&& (l >= Integer.MIN_VALUE) && (l <= Integer.MAX_VALUE)) {
relType = typeFactory.createSqlType(SqlTypeName.INTEGER);
} else {
relType = typeFactory.createSqlType(SqlTypeName.BIGINT);
}
{code}
The logic that I'm trying to apply is that: check if {{l}} is in the integer
range (to generate an INTEGER) only if {{l}} is the "right long value", i.e. it
did not overflow, and in order to check that we verify if we can rebuild the
original BigDecimal parameters using {{l}} and {{scale}}. Otherwise, generate a
BIGINT.
> AssertionError on RexBuilder when creating BigDecimal RexLiteral
> ----------------------------------------------------------------
>
> Key: CALCITE-2684
> URL: https://issues.apache.org/jira/browse/CALCITE-2684
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.17.0
> Reporter: Ruben Quesada Lopez
> Assignee: Julian Hyde
> Priority: Minor
> Fix For: 1.18.0
>
>
> The method {{RexBuilder#makeExactLiteral(java.math.BigDecimal)}} throws an
> AssertionError if the BigDecimal parameter has an unscaled value that
> overflows long:
> {code:java}
> public RexLiteral makeExactLiteral(BigDecimal bd) {
> ...
> long l = bd.unscaledValue().longValue(); // narrowing conversion
> BigInteter to long
> ...
> assert BigDecimal.valueOf(l, scale).equals(bd); // assert fails if l
> overflew long
> ...
> {code}
> Moreover, with the current implementation, it can be possible to have this
> AssertionError, even in the cases when the variable {{l}} would not be used
> at all (decimal number)
> {code:java}
> ...
> assert BigDecimal.valueOf(l, scale).equals(bd); // assert can fail, even if
> scale == 0 (l would not be needed)
> if (scale == 0) {
> if ((l >= Integer.MIN_VALUE) && (l <= Integer.MAX_VALUE))
> relType = typeFactory.createSqlType(SqlTypeName.INTEGER);
> else
> relType = typeFactory.createSqlType(SqlTypeName.BIGINT);
> } else {
> int precision = bd.unscaledValue().abs().toString().length();
> if (precision > scale)
> relType = typeFactory.createSqlType(SqlTypeName.DECIMAL, precision,
> scale);
> else
> relType = typeFactory.createSqlType(SqlTypeName.DECIMAL, scale + 1,
> scale);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
