weiqingy commented on code in PR #28437:
URL: https://github.com/apache/flink/pull/28437#discussion_r3418777987
##########
flink-table/flink-table-common/src/main/java/org/apache/flink/table/types/inference/TypeInferenceUtil.java:
##########
@@ -155,11 +158,45 @@ 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 literal must also fit
the expected type.
+ if (throwOnInferInputFailure) {
+ validateLiteralFitsExpectedType(callContext, pos,
expectedType);
+ }
}
return castCallContext;
}
+ /**
+ * Validates that a constant 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.
+ */
+ private static void validateLiteralFitsExpectedType(
+ CallContext callContext, int pos, DataType expectedType) {
+ if (!expectedType.getLogicalType().is(LogicalTypeRoot.DECIMAL)
Review Comment:
The method name and javadoc read as general ("fits the expected type on the
value level"), but the body only covers `DECIMAL` and returns early for
everything else — a `CHAR(2)` overrun or an out-of-range integer literal would
slip through the same way. Is decimal-only the intended scope for FLINK-39122
(other types a follow-up)? If so, would scoping the name/doc to decimal help a
later reader avoid assuming non-decimal value overflows are caught here?
--
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]
