Hi Andrei, I'm coming late to this discussion, but I agree with option B (labels as read-only projection over tag).
I think this reflects the current consensus. Cheers, Dmitri. On Sun, Oct 11, 2026 at 6:26 AM Andrei Tserakhau via dev < [email protected]> wrote: > Hi all, > > Now that the IRC "labels" field has merged in Iceberg Spec ([0]) and the > Polaris Tag work is close ([1]), I'd like to open a thread on how Polaris > should support labels. > > There are two ways Polaris could do labels: > > A) Labels as a separate entity - their own definitions/store, parallel to > Tags. > B) Labels as a projection over Tags - read-only IRC view / projection of > the existing tag model. > > I propose B. Tags already are the structured model: definitions, > assignments, allowed values, inheritance, reverse lookup. IRC labels are > designed as the flat read surface of such models (object-level key/values > plus per-field labels by field-id). A separate labels entity would > duplicate the tag model and create two sources of truth to reconcile; a > projection keeps one model with two surfaces, a structured authoring API > and an interoperable flat read field. Column identity already lines up: > Tags use the Iceberg field-id, and IRC labels fields are keyed by field-id. > > Given B, a Polaris catalog plays two roles: > > 1. Producer. Polaris resolves a target's effective tags (inheritance > applied, closest-wins) and projects them into IRC labels on > loadTable/loadView. The Tag API stays the authoring/management surface and > labels is the read projection for IRC compliant engines. > > 2. Consumer. When Polaris federates a foreign IRC catalog, it reads that > catalog's labels and stores them as tags owned by the source catalog: > read-only in Polaris and clearly marked as foreign. A Polaris user cannot > edit them (they change only when Polaris re-syncs from the source) and they > stay separate from Polaris's own natively-authored tags. That is how a > foreign catalog's metadata becomes usable in Polaris without pretending it > is local. > > Mostly I'd like the community read on whether projection-over-tags feels > right, and whether the producer/consumer split is worth keeping in mind in > the Tag design so the contract leaves room for it. Would like to hear if > this framing is wrong, or where a separate entity would actually serve > better. > > Thanks, > Andrei > > [0] IRC Labels spec PR - https://github.com/apache/iceberg/pull/15750 > [1] Tags discussion thread - > https://lists.apache.org/thread/28h8bvg3pwwmpob2p4gcrpfs1x5cgkmn >
