TheR1sing3un opened a new issue, #383: URL: https://github.com/apache/paimon-rust/issues/383
### Background #370 implements column-level ALTER TABLE. Its `RenameColumn` path (`TableSchema::apply_changes`) rewrites column references in `primary_keys`, `bucket-key`, and `sequence.field` — case 1 of Java `SchemaManager.applyRenameColumnsToOptions`. It does not yet rewrite field-scoped options whose key embeds the column name. Java handles two more cases: - **case 2** — key = `fields.<col>.<suffix>`, value has no column name: `aggregate-function`, `ignore-retract`, `distinct`, `list-agg-delimiter`. - **case 3** — key and value both contain column names: `fields.<cols>.sequence-group`, `fields.<cols>.nested-key`. ### Impact After a rename, such options still point at the old column name and are silently persisted. This is already latent for partial-update tables on `main` (`spec/partial_update.rs` supports `fields.<col>.sequence-group` / `fields.<col>.aggregate-function`): renaming a column carrying these leaves a stale key. It also composes with `merge-engine=aggregation` (#340), where a renamed aggregation value column would fall back to the default aggregator/delimiter at read time. ### Proposed fix Port case 2 and case 3 of Java `applyRenameColumnsToOptions` into the Rust `RenameColumn` handling, with tests covering rename of columns carrying `fields.<col>.*` options. ### References - @JingsongLi comment on #370 (2026-06-13) - Java `SchemaManager.applyRenameColumnsToOptions` -- 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]
