Hi JB, Thanks, good to keep the Glasgow conversation going. Glad we're aligned on opt B.
On your questions: 1/ Permissions / leakage: I'd reuse the existing tag visibility rules rather than add a label-specific privilege. On `loadTable` / `loadView`, labels would only include tags the caller is already allowed to see through the Tag API. Table access alone would not expose anything extra. 2/ Performance: Agreed, `loadTable` is too hot to resolve inheritance on every call. I'd cache the effective tags per table, invalidate on tag changes, then apply the caller-specific visibility filter on top. That should keep the added cost small. 3/ Default vs gated: I'd gate it initially with something like `polaris.label.enabled` per catalog, default off. We can move toward on-by-default later once the behavior and cost are proven. Best, Andrei On Mon, Oct 12, 2026 at 9:43 AM Jean-Baptiste Onofré <[email protected]> wrote: > Hi Andrei > > Thanks for starting this thread after our discussion during Lakehouse > Day/CommunityOverCode in Glasgow. > > I'm +1 to option B (labels as a read-only projection over tags). Tags > already have definitions, allowed values, inheritance and reverse lookup, > and both models are keyed by Iceberg field-id. A separate labels entity > would give us two source of truth to reconcile, with no benefit imho. > > The tag work isn't merged yet, so it's cheap (good timing :)) to reserve > what the consumer role needs. Postponing this later would be much more > painful. I would keep the actual federation impl out of the first tag PR. > > About collisions, "native wins" is reasonable. Polaris is the asserting > catalog at the point of access, so I'm fine with that rule. > > I have a few questions: > - We have to be careful that tag-definition visibility (permission) > doesn't leak through labels. Do we plan to see labels on loadTable/loadView > relying on the table read privileges? Or do we want specific privileges for > label/tag? > - Resolving tags with inheritence on every loadTable can be significant > for performence. What are your thoughts about that? Opt caching? > - Do we want to have label emitted by default, or do you want to guate by > catalog configuration (polaris.label.enabled=on)? > > Thanks! > Regards > JB > > On Sun, Oct 11, 2026 at 11: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 >> >
