MaxGekk opened a new pull request, #56409: URL: https://github.com/apache/spark/pull/56409
### What changes were proposed in this pull request? This PR adds support for casting between `DATE` and the nanosecond-precision timestamp types (`TIMESTAMP_NTZ(p)` and `TIMESTAMP_LTZ(p)`). Instead of teaching `Cast` to convert these types directly, it introduces a new analyzer rule `ResolveTimestampNanosCast` that rewrites such casts through the corresponding microsecond-precision timestamp type: - `DATE -> TIMESTAMP_NTZ/LTZ(p)` ==> `DATE -> TIMESTAMP_NTZ/TIMESTAMP -> TIMESTAMP_NTZ/LTZ(p)` - `TIMESTAMP_NTZ/LTZ(p) -> DATE` ==> `TIMESTAMP_NTZ/LTZ(p) -> TIMESTAMP_NTZ/TIMESTAMP -> DATE` Details: - `ResolveTimestampNanosCast` runs in the `Resolution` fixed-point batch right after `ResolveTimeZone`, and preserves the original cast's `timeZoneId` and `evalMode` on the rewritten nested casts. The micro-precision intermediate (`TIMESTAMP` for LTZ, `TIMESTAMP_NTZ` for NTZ) already supports casting to/from `DATE`, so the resulting expression resolves normally. - The rule is registered in `RuleIdCollection` so it participates in tree-pattern based pruning. - `Cast` is left mostly untouched: the only change is in `canANSIStoreAssign`, which now rejects `DATE <-> nanos` in both directions. Casting between `DATE` and a nanosecond timestamp drops the time-of-day (or fabricates it) and sub-microsecond digits, so it must be an explicit `CAST` rather than a silent store assignment. ### Why are the changes needed? `DATE` could not be cast to or from the nanosecond-precision timestamp types (`TIMESTAMP_NTZ(p)`/`TIMESTAMP_LTZ(p)`), so common date/time conversions failed for these new types. ### Does this PR introduce _any_ user-facing change? Yes. Users can now cast between `DATE` and `TIMESTAMP_NTZ(p)` / `TIMESTAMP_LTZ(p)`, e.g.: ```sql SELECT DATE '2020-01-01'::timestamp_ntz(9); SELECT TIMESTAMP_LTZ '2020-01-01 12:30:15.123456789'::date; ``` These casts previously failed; store assignment between the two types is still disallowed and requires an explicit `CAST`. ### How was this patch tested? - New `ResolveTimestampNanosCastSuite` covering the structural rewrite for all four `DATE <-> nanos` directions, `timeZoneId`/`evalMode` propagation, idempotence, rewrite inside a subquery, and end-to-end value/zone semantics. - New assertions in `CastSuiteBase` that `canANSIStoreAssign` rejects `DATE <-> nanos` in both directions. - New golden-file queries in `timestamp-ltz-nanos.sql` and `timestamp-ntz-nanos.sql`, with regenerated `analyzer-results` and `results` outputs. - `catalyst/scalastyle` and `catalyst/Test/scalastyle` pass. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Cursor (Claude 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]
