[
https://issues.apache.org/jira/browse/SPARK-60132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
L. C. Hsieh reassigned SPARK-60132:
-----------------------------------
Assignee: L. C. Hsieh
> Bound the integral-digit count of BigDecimal values in Decimal.set to avoid
> raw ArithmeticException for huge exponents
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: SPARK-60132
> URL: https://issues.apache.org/jira/browse/SPARK-60132
> Project: Spark
> Issue Type: Bug
> Components: SQL
> Affects Versions: 3.5.8, 4.2.0, 4.3.0, 4.1.3, 4.0.4, 4.4.0
> Reporter: L. C. Hsieh
> Assignee: L. C. Hsieh
> Priority: Major
>
> SPARK-60118 bounds the number of integral digits (precision - scale, now
> computed in Long) only in Decimal.fromString / fromStringANSI, i.e. the
> string-to-decimal cast path. Other entry points that build a Decimal from a
> BigDecimal have no such bound and can still fail with a raw
> java.lang.ArithmeticException (or spend a long time in BigDecimal.setScale)
> for values with a huge exponent:
> * Decimal.set(BigDecimal) computes this._precision = decimal.precision -
> decimal.scale as an Int, which overflows for e.g. 1e2147483647 or
> 0e2147483647, and then calls decimal.setScale(0). Decimal(String) and
> Decimal(java.math.BigDecimal) go through this.
> * Decimal.set(BigDecimal, precision, scale), used by Decimal(bd, precision,
> scale) and the CSV/JSON/XML readers, calls decimal.setScale(scale) without
> bounding the scale change. That method is tracked in SPARK-60133; this ticket
> covers Decimal.set(BigDecimal).
> Suggested direction: move the Long-based integral-digit bound into
> Decimal.set or a shared helper, so these paths don't depend on the
> string-cast fast path.
> Zero is a case of the first point: for a zero with a negative scale,
> precision - scale grows with the exponent although the value has one digit.
> For example, Literal(new java.math.BigDecimal("0E+39")) builds a Decimal with
> precision 40, and DecimalType.fromDecimal then fails with
> DECIMAL_PRECISION_EXCEEDS_MAX_PRECISION (0E+2147483647 gives precision
> -2147483648 and fails with DECIMAL_SCALE_EXCEEDS_PRECISION), while
> Literal(java.math.BigDecimal.ZERO) works. SPARK-60118 normalizes zero only in
> Decimal.fromString / fromStringANSI; handling zero in Decimal.set(BigDecimal)
> (precision 1 and scale 0 for a zero with a negative scale when negative
> scales are not allowed) would cover every entry point.
> Reported in the review of https://github.com/apache/spark/pull/59334.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
