github-actions[bot] commented on code in PR #64026:
URL: https://github.com/apache/doris/pull/64026#discussion_r3418573672
##########
fe/fe-core/src/main/java/org/apache/doris/planner/ScanNode.java:
##########
@@ -367,6 +382,64 @@ public static ColumnRanges expressionToRanges(Expr expr,
}
}
+ /**
+ * Re-type a literal value to the partition column's type when the two
+ * primitive types belong to the same family (fixed-point, date, string,
etc.)
+ * but differ in detail (e.g. INT vs BIGINT, DATE vs DATETIMEV2, STRING vs
+ * VARCHAR). This is necessary because {@link ColumnBound} delegates to
+ * {@link PartitionKey#compareLiteralExpr} which rejects cross-type
+ * comparisons. For example, a predicate {@code CAST(k AS BIGINT) = 1} on
an
+ * INT partition column produces a BIGINT-typed literal that would fail to
+ * compare against INT partition bounds.
+ *
+ * <p>The re-parse is a best-effort: if {@code value} already has the exact
+ * column type, or the types are in different families, it is returned
+ * unchanged.
+ */
+ @VisibleForTesting
+ static LiteralExpr normalizePartitionFilterLiteral(LiteralExpr value, Type
columnType) {
+ Type valueType = value.getType();
+ if (valueType.equals(columnType)) {
+ return value;
+ }
+ if (!valueType.isFixedPointType() && !valueType.isDateType()
+ && !valueType.isStringType() && !valueType.isDecimalV3()) {
+ return value;
+ }
+ // Only re-type within the same family.
+ if (!isSamePrimitiveFamily(valueType, columnType)) {
+ return value;
Review Comment:
This fallback still leaves same-family predicates in partition pruning with
a cross-type literal. A concrete path is a DATEV2 range-partition column with
`CAST(k AS DATETIMEV2) = DATETIMEV2 '2024-01-01 00:00:00'`:
`BinaryPredicate.getSlotBinding()` accepts the cast because
`CastExpr.canHashPartition()` returns true for date-family casts, then this
helper tries `LiteralExprUtils.createLiteral(value.getStringValue(),
Type.DATEV2)`. `DateLiteralUtils` rejects the datetime string for a DATEV2
target, so the catch returns the original DATETIMEV2 literal. From there
`ColumnBound.compareTo()` compares DATETIMEV2 filter bounds to DATEV2 partition
bounds, and after this PR `DateLiteral.compareLiteral()` rejects exact type
mismatches, so the range ordering used by partition pruning can be wrong and
the matching partition can be dropped.
This is distinct from the earlier exact-type comparator thread: this is the
new normalization path added to address that issue, but the fallback still
preserves the cross-type date bound (and
`ScanNodePartitionTypeNormalizationTest` currently asserts that behavior).
Please either construct a lossless target-typed date literal when the value is
representable, or signal conversion failure so this predicate is not used for
pruning; then add a regression/unit test for the casted date partition
predicate.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
