github-actions[bot] commented on code in PR #66761:
URL: https://github.com/apache/doris/pull/66761#discussion_r3860961235
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/util/TypeCoercionUtils.java:
##########
@@ -1338,8 +1487,28 @@ public static Expression
processComparisonPredicate(ComparisonPredicate comparis
left = comparisonPredicate.left();
right = comparisonPredicate.right();
+ if (isTimeStampNsAndCompatibleDateTimePair(left.getDataType(),
right.getDataType())
Review Comment:
[P1] Preserve exact mixed-temporal comparison semantics
This branch strictly casts every mixed `TIMESTAMP_NS`/`DATETIME(V2)` operand
to the narrower `TIMESTAMP_NS` domain (and the join arm does the same for
`DATE`/`DATEV2`). Legal values such as `DATETIMEV2 '9999-12-31'` therefore
abort a scalar comparison or an otherwise non-matching join, even though BE
already has the exact mixed `TIMESTAMP_NS`/`DATETIMEV2` comparator below this
coercion path and their ordering/equality is determinate. Please let ordinary
comparisons reach that exact kernel and make join-key normalization range-safe
(with an exact residual if needed), then change the current expected-error
comparison/join cases to result and outer-join coverage.
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/functions/scalar/NullIf.java:
##########
@@ -65,7 +65,7 @@ public FunctionSignature customSignature() {
Optional<DataType> commonType;
try {
commonType = TypeCoercionUtils.findWiderTypeForTwoByVariable(
- getArgumentType(0), getArgumentType(1), false, true);
+ child(0), child(1), false, true);
Review Comment:
[P1] Keep NULLIF's comparison-only operand range-safe
This custom signature gives both arguments the same `TIMESTAMP_NS` type, so
`implicitCastInputTypes()` system-strictly narrows an out-of-range `DATETIMEV2`
peer before `NULLIF` can compare it. For example, `nullif(TIMESTAMP_NS
'1970-01-01', DATETIMEV2 '2500-01-01')` aborts instead of returning its
unchanged first argument. Unlike `CASE` or `COALESCE`, `NULLIF`'s result is
always argument 0; BE already implements it as mixed equality followed by
argument 0 and this PR supplies the exact mixed comparator. Please preserve
argument 0's result type without narrowing the comparison-only peer, and add
both-order out-of-range literal/column coverage for folded and runtime
execution.
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/functions/SearchSignature.java:
##########
@@ -255,6 +267,37 @@ private Pair<Boolean, Pair<Integer, Integer>>
doMatchTypes(FunctionSignature sig
DataType sigArgType = sig.getArgType(i);
Expression argument = arguments.get(i);
DataType realType = argument.getDataType();
+ if (hasTimeStampNsArgument &&
hasTimeStampNsCompatibleDateTimeArgument && hasDateLikeSignature
+ && realType.isDateLikeType() &&
!sigArgType.isDateLikeType()) {
+ // Do not bypass temporal exactness checks through a generic
string overload.
+ return Pair.of(false, Pair.of(stringLiteralCoersionCount,
timeZoneCoersionScore));
+ }
+ if (hasTimeStampNsArgument &&
hasTimeStampNsCompatibleDateTimeArgument && hasDateLikeSignature
Review Comment:
[P1] Keep the exact mixed datediff overloads reachable
This condition rejects the new `(TIMESTAMP_NS, DATETIMEV2)` and inverse
`datediff` signatures themselves, so resolution falls back to `(TIMESTAMP_NS,
TIMESTAMP_NS)` and `implicitCastInputTypes()` strictly narrows the wider
operand. A valid value such as `DATETIMEV2 '2500-01-01'` then aborts even
though the BE mixed `datediff` kernel registered in this change only compares
`daynr()` and can return the finite result directly. Please let exact mixed
physical signatures match before applying homogeneous `TIMESTAMP_NS`
normalization, and replace the overflow expectation with
both-order/out-of-range result coverage; audit scalar diff siblings for the
same avoidable narrowing.
--
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]
