mihaibudiu commented on code in PR #3589:
URL: https://github.com/apache/calcite/pull/3589#discussion_r1695828675
##########
core/src/main/java/org/apache/calcite/sql/validate/SqlValidatorImpl.java:
##########
@@ -3334,20 +3333,14 @@ private void registerOperandSubQueries(
@Override public void validateLiteral(SqlLiteral literal) {
switch (literal.getTypeName()) {
case DECIMAL:
- // Decimal and long have the same precision (as 64-bit integers), so
- // the unscaled value of a decimal must fit into a long.
-
- // REVIEW jvs 4-Aug-2004: This should probably be calling over to
- // the available calculator implementations to see what they
- // support. For now use ESP instead.
- //
- // jhyde 2006/12/21: I think the limits should be baked into the
- // type system, not dependent on the calculator implementation.
- BigDecimal bd = literal.getValueAs(BigDecimal.class);
- BigInteger unscaled = bd.unscaledValue();
- long longValue = unscaled.longValue();
- if (!BigInteger.valueOf(longValue).equals(unscaled)) {
- // overflow
+ // Accept any decimal value that does not exceed the max
+ // precision of the type system.
+ final RelDataTypeSystem typeSystem = getTypeFactory().getTypeSystem();
+ final int maxPrecision = typeSystem.getMaxNumericPrecision();
+ final BigDecimal bd = literal.getValueAs(BigDecimal.class);
+ final BigDecimal noTrailingZeros = bd.stripTrailingZeros();
+ // If we don't strip trailing zeros we may reject values such as
1.000....0.
+ if (noTrailingZeros.precision() > maxPrecision) {
Review Comment:
I added this check, no tests required changes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
