Renaming a column corrupts field-scoped options: nested renames, spaced CSV entries, and clustering.columns

[LuciferYang]

Search before asking

• I searched in the issues and found no similar issues.

Paimon version

master (1.5-SNAPSHOT)

Compute Engine

Any engine issuing ALTER TABLE ... RENAME COLUMN.

Minimal reproduce step

Renaming a column rewrites the field-referencing table options so they follow the new name. SchemaManagerUtils.applyRenameColumnsToOptions mishandles three cases.

1. Nested renames are keyed by their root column. Rename a nested field such as metrics.value.f1 to f100 on a shredded MAP column that carries fields.metrics.map.storage-layout=shared-shredding. The option is relocated to fields.f100.map.storage-layout, so the still-named metrics column loses its shredding config and the option references a column that does not exist. Two nested renames under the same root throw IllegalStateException: Duplicate key from the toMap collector.

2. CSV option entries are split without trimming, while the canonical readers (bucket-key, sequence.field, clustering.columns, sequence-group) all trim. With bucket-key = 'a, b', renaming b to c fails to match the b entry, the value stays a, b, and the next commit aborts because validation trims to [a, b] and finds b gone.

3. clustering.columns (and its fallback key sink.clustering.by-columns) is not rewritten, so renaming a clustering column leaves the option pointing at the dropped name.

What doesn't meet your expectations?

After a rename, every field-referencing option should follow the new column name. Instead the options above are dropped, relocated to a non-existent column, crash the rename, or later abort a commit.

Anything else?

No response

Are you willing to submit a PR?

• I'm willing to submit a PR!