LuciferYang opened a new pull request, #57486:
URL: https://github.com/apache/spark/pull/57486

   ### What changes were proposed in this pull request?
   
   `ToTime` (the `to_time` function) is a `RuntimeReplaceable`, so its 
`dataType` comes from `replacement.dataType`. When the format argument is 
foldable and evaluates to NULL, the replacement fell back to `Literal(null, 
expr.dataType)`, where `expr` is the format argument, so the whole expression 
reported the format's type (STRING) instead of TIME. This changes the fallback 
to `Literal(null, TimeType())`, so `to_time` reports `TimeType()` like all of 
its other branches.
   
   ### Why are the changes needed?
   
   `to_time(str, fmt)` with a foldable NULL `fmt` reports the wrong type. 
`SELECT typeof(to_time('00:12:00', null))` returns `string` instead of 
`time(6)`, and the analyzed plan carries STRING for that column, so schema 
inference and UNION type coercion (against a real TIME column) use the wrong 
type. The value is NULL either way, but the type is user-visible and wrong. The 
inconsistency is also internal: a non-foldable NULL format takes the 
`invokeParser()` branch and correctly yields `time(6)`, so the result type 
depended on whether the format happened to be foldable.
   
   ### Does this PR introduce _any_ user-facing change?
   
   Yes. `to_time(str, fmt)` with a foldable NULL `fmt` now has type `time(6)` 
instead of STRING, consistent with all other forms of `to_time`. The returned 
value (NULL) is unchanged. This is a bug fix: the wrong type has been present 
since `to_time` was introduced in 4.1.0.
   
   ### How was this patch tested?
   
   Added a `TimeExpressionsSuite` case asserting `ToTime(...).dataType === 
TimeType()` for both an untyped and a STRING-typed foldable NULL format; it 
fails on the unfixed tree with `StringType did not equal TimeType(6)`. The same 
case also asserts the value is still NULL via `checkEvaluation`. Also added two 
golden queries in `time.sql` whose schema now locks in `time(6)`.
   
   ### Was this patch authored or co-authored using generative AI tooling?
   
   Generated-by: Claude Code (Opus 4.8)
   


-- 
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]

Reply via email to