Thanks, good questions! On (1), store vs. forward:
Forwarding the foreign labels straight through on loadTable is fine, and for an engine that just reads the table it's probably the simpler default, Polaris doesn't need to store anything to pass them along. The reason to represent them as tags is about Polaris users, not the wire. Because we're treating labels as a projection over Tags (no separate labels entity), there's no other surface to show a federated table's classifications through Polaris's own read / discovery / reverse-lookup APIs. Representing them as foreign, read-only tags is the only coherent way to make them visible there. And "represent as tags" doesn't have to mean "persist" - it can be ephemeral, resolved from the source on read and never stored. Caching them is an optimization (avoids a live round-trip to the source on every read, and an availability dependency on it), not a requirement. So: pass-through for the engine read path, foreign read-only tags for Polaris-side visibility, caching optional / follow up. On (2), can owners tag a federated table, and collisions: Yes, I'd allow it. Enriching a federated table with local classification is one of the main reasons to federate it in the first place. On collisions: in the tag representation there isn't really one, because foreign tags carry source attribution and are read-only while native tags are locally owned. An owner from the source and an owner adds locally coexist - they're distinguishable by origin, and adding the native one doesn't overwrite or edit the foreign one. The collision only has to be resolved at the flat labels wire, where there's one value per key. There I'd propose native (local) wins: at the point Polaris serves the table it is the asserting catalog, so its own classification is authoritative, with the foreign value preserved underneath via attribution. That's consistent with the spirit of IRC labels: a catalog presents what it asserts at the point of access. Best, Andrei On Sun, Oct 11, 2026 at 11:40 AM Sung Yun <[email protected]> wrote: > Hi Andrei, > > Thanks for starting this discussion. I agree it would be good to think > about how the relationship between tags and labels should be mapped if any. > > As a Producer, I generally agree with your proposal of sourcing the labels > from tags, as the alternative would be to introduce a different first class > entity that is stored within Polaris. > > Regarding your proposal for consuming labels for federated catalogs I have > two questions: > 1. Is there a reason why we’d need to store the federated labels as tags, > instead of just directly forwarding the labels to the client? > 2. Would data owners be allowed to attach tags/labels in Polaris for a > federated table? > If so, how do you think we should handle label naming collisions between > native Polaris labels and federated labels? > > Sung > > On Sun, Oct 11, 2026 at 11:28 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 > > >
