[
https://issues.apache.org/jira/browse/CALCITE-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5877:
------------------------------------
Labels: pull-request-available (was: )
> Calcite crashes with AssertionError when compiling MOD with arguments with
> large scales
> ---------------------------------------------------------------------------------------
>
> Key: CALCITE-5877
> URL: https://issues.apache.org/jira/browse/CALCITE-5877
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.35.0
> Reporter: Mihai Budiu
> Priority: Minor
> Labels: pull-request-available
>
> Adding the following test to RelToSqlConverterTest produces an
> AssertionFailure:
> {code:java}
> @Test void testNumericScaleMod() {
> final String sql = "SELECT MOD(CAST(2 AS DECIMAL(39, 20)), 2)";
> final String expected = "";
> sql(sql).withPostgresqlModifiedDecimalTypeSystem()
> .ok(expected);
> }
> {code}
> The exception is here:
> {code:java}
> java.lang.AssertionError
> at
> org.apache.calcite.rel.type.RelDataTypeSystem.deriveDecimalModType(RelDataTypeSystem.java:383)
> at
> org.apache.calcite.sql.type.ReturnTypes.lambda$static$11(ReturnTypes.java:849)
> at
> org.apache.calcite.sql.type.SqlTypeTransformCascade.inferReturnType(SqlTypeTransformCascade.java:58)
> at
> org.apache.calcite.sql.type.SqlReturnTypeInferenceChain.inferReturnType(SqlReturnTypeInferenceChain.java:55)
> {code}
> In this line:
> {code:java}
> int scale = Math.max(s1, s2);
> assert scale <= getMaxNumericScale();
> {code}
> I suspect that doing a Math.max with the getMaxNumericScale (instead of an
> Assert) is sufficient to fix this particular problem. The question is whether
> the compiler should really enforce the invariant that this assertion checks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
