Disable test_read_hive_fixed_length_char on Spark 3.4+.

[mythrocks]

Fixes #8321.

This commit disables test_read_hive_fixed_length_char for Spark 3.4 until #8324 is resolved (i.e. the change in behaviour of CHAR columns is addressed).

[mythrocks]

Build

[tgravescs]

so to be clear, by disabling the test, we fallback to the CPU here? want to ensure since #8324 is marked low priority. If that is the case should we have test to verify it falls back? Maybe not required just asking

[mythrocks]

It's not a fallback, exactly.

On 3.4, Spark adds a code-gen step to modify the results (i.e. pad the result column out to the required width). That step causes the Project exec to fall off the GPU:

+- *(1) Project [staticinvoke(class org.apache.spark.sql.catalyst.util.CharVarcharCodegenUtils, StringType, readSidePadding, foo#20, 3, true, false, true) AS foo#24]
   +- GpuColumnarToRow false
      +- GpuFileGpuScan orc spark_catalog.default.foobar[foo#20] Batched: true, DataFilters: [], Format: ORC, Location: InMemoryFileIndex[file:/tmp/foobar], PartitionFilters: [], PushedFilters: [], ReadSchema: struct<foo:string>

I don't know if it's worth adding a test verifying that Project isn't on GPU on 3.4. But I'm open to suggestions/improvements.

[tgravescs]

ok main thing is it falls back and doesn't fail, I'm fine with skipping test since we have the issue to track.

[mythrocks]

Actually, you've convinced me. I've added an equivalent test on 3.4, allowing for ProjectExec fallback.

You're right. It would be best to codify that that the GPU results match the CPU results, even when ProjectExec falls back.

[mythrocks]

Build

[mythrocks]

Build