asolimando commented on code in PR #3589:
URL: https://github.com/apache/calcite/pull/3589#discussion_r1694762786


##########
core/src/main/java/org/apache/calcite/sql/SqlNumericLiteral.java:
##########
@@ -103,7 +103,7 @@ public boolean isExact() {
           BigDecimal bd = getValueNonNull();
           SqlTypeName result;
           // Will throw if the number cannot be represented as a long.
-          long l = bd.longValue();
+          long l = bd.longValueExact();

Review Comment:
   Sorry, I didn't notice that part of the code below was "collapsed" in the 
UI, thanks for the clarification



##########
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 think we should, I can't think of any reason why we should not, do you 
have anything in mind?
   
   To this extend, we could use
   
[BigDecimal::scale()](https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html#scale--)
 to check compatibility with what the type system supports.
   
   WDYT?



-- 
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]

Reply via email to