MaxGekk opened a new pull request, #56540: URL: https://github.com/apache/spark/pull/56540
### What changes were proposed in this pull request? [SPARK-57469](https://issues.apache.org/jira/browse/SPARK-57469) introduced the `AnyTimestampNanoType` abstraction (an `AbstractDataType` plus the `AnyTimestampNanoTypeExpression` extractor), but it was used in only one place. Meanwhile, many sites across catalyst/core/hive still discriminated on the nanosecond-precision timestamp types by spelling out the pair explicitly, e.g.: ```scala case _: TimestampNTZNanosType | _: TimestampLTZNanosType => ... t.isInstanceOf[TimestampNTZNanosType] || t.isInstanceOf[TimestampLTZNanosType] ``` This PR centralizes that check: - Follow the existing `AnyTimeType` design: add a companion `abstract class AnyTimestampNanoType extends DatetimeType { def precision: Int }` and make `TimestampNTZNanosType` / `TimestampLTZNanosType` extend it (their `precision` constructor `val` implements the abstract `def`). This lets the abstraction be used as a plain type pattern `case _: AnyTimestampNanoType`. - Simplify `AnyTimestampNanoType.acceptsType` and `AnyTimestampNanoTypeExpression` to `isInstanceOf[AnyTimestampNanoType]`. - Replace the explicit `TimestampNTZNanosType` + `TimestampLTZNanosType` pair-checks across type-coercion, codegen, projections, hashing, and data-source `supportDataType` checks with `case _: AnyTimestampNanoType`. Sites that treat the two types differently (distinct converters/ops, per-type instance construction, the `EXTRACT` error-message builder, parsers, physical-type maps) are intentionally left unchanged. This is a sub-task of [SPARK-56822](https://issues.apache.org/jira/browse/SPARK-56822) (SPIP: Timestamps with nanosecond precision). ### Why are the changes needed? The pair-checks are duplicated logic that must be kept in sync whenever the set of nanosecond timestamp types changes. Reusing the abstraction removes the duplication and gives a single place that defines "is a nanosecond-precision timestamp type". ### Does this PR introduce _any_ user-facing change? No. The change is behavior-preserving: no user-facing change and no new functionality. Because the nanosecond timestamp types are an unreleased preview feature, changing their superclass has no binary-compatibility impact (verified with MiMa). ### How was this patch tested? - Compiled the affected modules: `build/sbt sql-api/compile catalyst/compile sql/compile hive/compile avro/compile`. - `./dev/scalastyle` and `dev/mima` pass. - Existing nanosecond-timestamp test coverage continues to apply (no behavior change). ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Cursor -- 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]
