[Bug](nereids) Ordered constant folding throws ClassCastException for TIME literals

[Baymine]

Search before asking

• I searched the issues and found no similar issue.

Version

master

What's Wrong?

Nereids FE constant folding unconditionally casts operands of ordered comparisons (>, >=, <, and <=) to ComparableLiteral after their children are folded.

Functions such as curtime() fold to TimeV2Literal, which extends Literal but does not implement ComparableLiteral. As a result, expressions such as curtime() >= '20:00:00' can fail during planning with ClassCastException.

What You Expected?

Ordered comparisons whose folded operands do not implement ComparableLiteral should remain as predicates for later evaluation instead of crashing during FE constant folding.

How to Reproduce?

Run a query containing an ordered comparison over curtime(), for example:

SELECT curtime() >= '20:00:00';

Proposed Fix

Guard ordered comparison folding by checking that both operands implement ComparableLiteral. Fold when both are comparable; otherwise preserve the rewritten comparison expression.

[Doris-Breakwater]

Breakwater-GitHub-Analysis-Slot: slot_e2a072a96813

This content is generated by AI for reference only.

Initial assessment: confirmed FE/Nereids constant-folding bug. I checked the current public master head (ef1d741df4ed40f081321100c08cc4c41a701d32) as well as the local source snapshot. The issue currently has no labels, assignee, milestone, or linked PR; suggested ownership is Nereids FE expression rewriting/constant folding.

Verified facts:

• FoldConstantRuleOnFE rewrites the children and calls preProcess(), but once both children are literals, each of visitGreaterThan, visitGreaterThanEqual, visitLessThan, and visitLessThanEqual casts both operands directly to ComparableLiteral.
• DateTimeAcquire.curTime() and currentTime() return TimeV2Literal. TimeV2Literal extends Literal and does not implement ComparableLiteral.
• During comparison coercion, a character literal such as '20:00:00' can be converted to the other operand's TIMEV2 type. The fold then reaches the unchecked cast with literal operands, explaining the reported ClassCastException during planning.
• Primitive TIMEV2 comparisons are accepted by comparison type checking and can be translated for execution. Therefore, preserving the rewritten predicate when FE cannot compare the literal classes is consistent with the existing execution path; this is a mismatch in the FE folding domain, not evidence that the SQL comparison itself is unsupported.
• Equality paths already handle non-ComparableLiteral operands without this unchecked ordered cast, so the immediate scope is the four ordered operators.

Recommended fix:

1. After child rewriting and preProcess(), fold an ordered comparison only when both operands implement ComparableLiteral; otherwise return the rewritten comparison predicate unchanged. Applying the same helper or guard to all four visitors will avoid asymmetric coverage.
2. Keep adding ComparableLiteral semantics to TimeV2Literal as a separate design option only if FE-side ordering is desired. That alternative needs explicit tests for negative times, fractional scales, and the cross-literal comparison contract; it is not necessary for the minimal crash fix.
3. Add focused FE unit coverage for >, >=, <, and <= with non-comparable TimeV2Literal operands, plus a positive control showing existing comparable literals still fold to BooleanLiteral.
4. Add a Nereids regression that executes the reported SELECT curtime() >= '20:00:00' (and preferably current_time/precision variants) and verifies planning/execution completes without an exception. The result is time-dependent, so the regression should test successful execution rather than hard-code a boolean value.

Missing but non-blocking information:

• The report says master but does not include the exact reporter-side commit SHA or full FE exception stack. Those would help pin the affected revision and confirm the precise optimizer entry point, especially if reproduction differs locally.
• If a maintainer cannot reproduce, please also capture relevant constant-folding/type-coercion session variables. No query profile or storage/BE logs are needed for this failure mode.

Impact appears limited to planning expressions whose folded ordered-comparison operands are literal classes outside the ComparableLiteral contract; it causes query failure but there is no indication of data corruption.