MaxGekk commented on code in PR #56375:
URL: https://github.com/apache/spark/pull/56375#discussion_r3411630792
##########
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/Cast.scala:
##########
@@ -415,6 +429,16 @@ object Cast extends QueryErrorsBase {
// This conversion stays explicit-only.
case (_: TimestampNTZNanosType, TimestampNTZType) => false
case (_: TimestampLTZNanosType, TimestampType) => false
+ // SPARK-57323: DATE <-> nanosecond-precision timestamp requires an
explicit CAST in both
Review Comment:
Yes, this is deliberate. I want DATE -> nanos to stay explicit-cast-only for
now rather than inherit the micro `(_: DatetimeType, _: DatetimeType) => true`
store-assignment catch-all. The reasoning is the compatibility argument you
quoted: while the nanos types are unreleased, starting strict is safe, and
loosening it later (allowing the store assignment) is backward-compatible,
whereas tightening after release would not be. So I'd prefer to ship it strict
and revisit if there is demand to match micro. I kept the explanatory comment
in `canANSIStoreAssign` and added `canUpCast` guard assertions in
`CastSuiteBase`, so the strictness stays intentional rather than accidental.
On the `forceNullable` note: agreed, returning `false` for nanos NTZ -> DATE
is intentional and more precise, since these conversions never turn a non-null
input into NULL. I'd leave the micro catch-all as-is; converging it is out of
scope for this PR.
--
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]
