rionmonster commented on code in PR #28437:
URL: https://github.com/apache/flink/pull/28437#discussion_r3707931610
##########
flink-table/flink-table-common/src/main/java/org/apache/flink/table/types/inference/TypeInferenceUtil.java:
##########
@@ -155,11 +158,59 @@ private static CallContext castArgumentsInternal(
"Invalid argument type at position %d. Data
type %s expected but %s passed.",
pos, expectedType, actualType));
}
+
+ // Beyond type-level castability, a constant DECIMAL literal must
also fit the
+ // expected type on the value level.
+ if (throwOnInferInputFailure) {
+ validateDecimalLiteralFitsExpectedType(callContext, pos,
expectedType);
+ }
}
return castCallContext;
}
+ /**
+ * Validates that a constant {@code DECIMAL} literal argument fits the
expected type on the
+ * value level and not only on the type level. For example, {@code
123.456} is implicitly
+ * castable to a {@code DECIMAL(2, 2)} but would otherwise be silently
reduced to {@code NULL}
+ * during constant folding instead of raising a type error.
+ *
+ * <p>Only {@code DECIMAL} is covered here; other value-level overflows
(e.g. {@code CHAR}
+ * overruns or out-of-range integer literals) are out of scope for this
check.
+ */
+ private static void validateDecimalLiteralFitsExpectedType(
+ CallContext callContext, int pos, DataType expectedType) {
+ if (!expectedType.getLogicalType().is(LogicalTypeRoot.DECIMAL)) {
Review Comment:
Good catch @Timm0!
I was able to confirm this behavior and swapped out the type-root check with
an `instanceof DecimalType`. I also went ahead and added in a separate
regression test to reproduce the `ClassCastException` (and ensure the new guard
prevents it).
--
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]
