Hi everyone, Following the discussion on IRC Labels [1 <https://github.com/apache/iceberg/issues/15521>] and the catalog syncs, I'd like to call a vote on the read-path spec change: an optional `labels` field on LoadTableResult and LoadViewResult.
Labels give catalogs a standard channel to surface the enrichment they already hold about an object -- semantic hints, classification, cost attribution, ownership-as-the-catalog-sees-it -- as flat key-value metadata that engines and other systems can read. The full motivation, scope, alternatives (including why this is separate from table properties), and the Kubernetes-labels precedent are in the design doc [2 <https://docs.google.com/document/d/1aj-6JlfBiMYEEVtNuh5WLMOrRQiMCcyYUGbouPM4hXI/edit>]; I'd encourage reading it before voting. Scope of this vote, deliberately narrow: - Read path only. The write path (UpdateLabels) and any structured/first-class tag entity are separate follow-up tracks, not part of this vote. - Flat key-value on the wire. The spec defines the envelope, not a vocabulary or a key registry -- conventions emerge in the community layer. - Additive and backward compatible: `labels` is optional; older clients ignore it. Design doc: [2 <https://docs.google.com/document/d/1aj-6JlfBiMYEEVtNuh5WLMOrRQiMCcyYUGbouPM4hXI/edit> ] Proposal: [1 <https://github.com/apache/iceberg/issues/15521>] Spec PR: [3 <https://github.com/apache/iceberg/pull/15750>] Prototype (Trino demo + Polaris implementation): [4 <https://github.com/laskoviymishka/irc-labels>] Please vote within the next 72 hours: [ ] +1 Adopt the labels read-path spec change [ ] +0 [ ] -1 Do not adopt, because ... [1] https://github.com/apache/iceberg/issues/15521 [2] https://docs.google.com/document/d/1aj-6JlfBiMYEEVtNuh5WLMOrRQiMCcyYUGbouPM4hXI/edit [3] https://github.com/apache/iceberg/pull/15750 [4] https://github.com/laskoviymishka/irc-labels Thanks, Andrei
