jackylee-ch opened a new pull request, #909: URL: https://github.com/apache/paimon-rust/pull/909
A sorted global index is read with a comparator built from the column's *current* type, but its keys were written with the type it had at build time — and no index file records a schema id. `UpdateColumnType` guards partition, primary-key, bucket-key and primary-key-index columns, not global-index ones. So `ALTER TABLE t ALTER COLUMN id TYPE BIGINT` on a btree-indexed `INT` column is accepted, and the next `WHERE id = 7` panics with `range end index 8 out of range for slice of length 4` inside the scan. `TIMESTAMP(3)`→`TIMESTAMP(6)` and the multivalue ARRAY element type reach the same place. `KeyComparator` now returns `Result<Ordering>` and each arm checks the width it reads, so no stored key can crash a query. A failure means the index cannot answer: the all-match shortcut reports nothing, `may_match` answers "may match" rather than "cannot match", and a failed query declines the entry so the predicate falls through to the read pipeline. On the build side a failure aborts the build. Out of scope: a cast whose new encoding accepts the stored key's width still reads those bytes as the new type — `INT`→`FLOAT`, a `DECIMAL` scale change, any numeric→`DECIMAL(p > 18)` (BigInteger accepts 1 to 16 bytes). Those give a wrong ordering, not a panic; separating a foreign key from a real one needs the build-time type, which is not recorded. -- 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]
