[SPARK-60397][SQL] Fix ORC filter pushdown on nanosecond timestamp columns read with a lower precision - #59654

What changes were proposed in this pull request?

This PR aims to fix the ORC filter pushdown on TIMESTAMP_LTZ(p) and TIMESTAMP_NTZ(p) columns when the ORC file was written with a higher precision than p.

Since SPARK-57823 (#57681), ORC pushes down the predicates on these columns. However, the ORC reader truncates the stored nanoseconds to the read precision (SPARK-57455, #56557), while ORC evaluates a pushed down predicate against the stored values. Unlike Parquet (SPARK-60380, #59641), an ORC file schema has the written precision through the Catalyst type attribute (spark.sql.catalyst.type), and OrcFilters.createFilter builds a SearchArgument for each file from its file schema. So, this PR keeps the predicates with a value when the read precision is not lower than the written precision, and pushes down only IsNull and IsNotNull otherwise.

• OrcTypeOps.acceptsReadType is added (default true), like ParquetFilterOps.acceptsReadType of SPARK-60358 ([SPARK-60358][SQL] Fix Parquet filter pushdown on TIME columns read with a lower precision #59606). The ops of TIMESTAMP_LTZ(p) and TIMESTAMP_NTZ(p) return true only for TIMESTAMP_LTZ(q) and TIMESTAMP_NTZ(q) with q >= p, respectively.
• OrcFilters.createFilter gets the read schema (requiredSchema in V1, readDataSchema in V2) and checks acceptsReadType before it converts a predicate with a value on a Types Framework field.

A foreign ORC timestamp column without the attribute cannot be read with the nanosecond timestamp types (UNSUPPORTED_FEATURE.ORC_TYPE_CAST), so the written precision is always known here. Since it is known only for each file, the pushed filters in the query plan are not changed.

Why are the changes needed?

The query results are wrong. For example, 00:00:00.123456789 is read as 00:00:00.1234567 with TIMESTAMP_NTZ(7), but the pushed down = compares the literal with the stored value.

// spark.sql.timestampNanosTypes.enabled=true
sql("SELECT CAST('1970-01-01 00:00:00.123456789' AS TIMESTAMP_NTZ(9)) AS ts UNION ALL " +
  "SELECT CAST('1970-01-01 00:00:01' AS TIMESTAMP_NTZ(9))").coalesce(1).write.orc("/tmp/nanos")

val df = spark.read.schema("ts TIMESTAMP_NTZ(7)").orc("/tmp/nanos")

df.collect()
// Array([1970-01-01T00:00:00.123456700], [1970-01-01T00:00:01])

df.where("ts = CAST('1970-01-01 00:00:00.1234567' AS TIMESTAMP_NTZ(7))").collect()
// Array()

<=>, <= and IN return no rows in the same way, with both V1 and V2, with both the vectorized and the row-based readers, and for TIMESTAMP_LTZ too. The expected result is Array([1970-01-01T00:00:00.123456700]), which is the result with spark.sql.orc.filterPushdown=false.

Does this PR introduce any user-facing change?

Yes, this fixes the wrong query results in the unreleased branches (master, branch-4.x and branch-4.3), including v4.3.0-rc1 (2026-08-31) and v4.3.0-rc2 (2026-10-12). The predicates with a value are not pushed down anymore only for the files written with a higher precision than the read precision. The nanosecond timestamp types are a preview feature, which is disabled by default (spark.sql.timestampNanosTypes.enabled).

How was this patch tested?

Pass the CIs with the newly added test cases in OrcFilterSuite and OrcV1FilterSuite. The end-to-end test case fails without this fix.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Opus 5.5