fix: field name mismatch when alter table rename caused by FieldMappingReader

[duanyyyyyyy]

Purpose

The check does not consider column name change. When a user does pure ALTER TABLE RENAME COLUMN with no other schema change:

• non_partition_data_schema[i].Name() = file's physical column name (pre-rename, e.g. age)
• non_partition_read_schema[i].Name() = query's logical column name (post-rename, e.g. years)
• Field ids are identical (RENAME doesn't change ids); idx mapping is identity; types unchanged; no non-exist fields

All four flag conditions evaluate to false → need_mapping_ = false → PASSTHRU.

The inner reader (e.g. paimon-cpp builtin parquet reader) emits the batch with the file's physical column name (age). The consumer (e.g. StarRocks BE) then looks up columns by their post-rename logical name
(years) using RecordBatch::GetColumnByName and gets a null shared_ptr. A subsequent member access on the null array dereferences nullptr → SIGSEGV.

This was missed by the existing TestAppendReadWithSchemaEvolution integration tests because they always combine RENAME with ADD COLUMN, which independently forces need_mapping_ = true via
non_exist_field_info_.

Tests

Added FieldMappingReaderTest.TestReadWithSchemaEvolutionPureRename:

• File schema: (f0:utf8, f1:int32) with field ids (0, 1)
• Read schema: (name_new:utf8, age_new:int32) with same field ids (0, 1) (pure RENAME)
• Asserts the result ChunkedArray matches the expected one — arrow::ChunkedArray::Equals compares both data values and schema field names, so a passthrough of the file's old names would fail the assertion.

Without the fix this test fails (Equals returns false due to field name mismatch).

API and Format

Documentation

Generative AI tooling

opus 4.7

[lxy-9602]

+1