szehon-ho commented on PR #16727: URL: https://github.com/apache/iceberg/pull/16727#issuecomment-4676137976
## Design options considered for the "specific name" There were two ways to give an overload a stable, user-facing handle: **Option A — a separate `specific-name` field.** Keep `definition-id` strictly derived from the signature and add a new optional `specific-name` field. Pros: maps 1:1 onto the SQL standard's two-name model and preserves the verifiable invariant that `definition-id == canonical(parameters)`. Cons: introduces a second identifier and a second reference key (e.g. `definition-log` would have to choose which one to record). **Option B — make `definition-id` optionally user-specifiable (chosen).** Let `definition-id` default to the canonical parameter-type tuple but allow a user-specified value. Pros: no new field, reuses the existing `definition-log` reference mechanism, smallest surface area. Cons: `definition-id` is no longer always the canonical signature, so it can't be recomputed/validated from `parameters` alone, and uniqueness must be stated explicitly rather than implied by the signature. ### Decision We went with **Option B**. Keeping a single identifier (rather than two) and not adding a second reference key to `definition-log` outweighed the loss of the "ID always equals the canonical signature" invariant, which we recovered by stating the uniqueness rule explicitly and keeping the canonical form as the default. Overload resolution continues to use `parameters`, so making `definition-id` user-specifiable does not affect resolution. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
