I think that this is a reasonable way to solve some persistent issues that we've seen.
Many catalogs track additional metadata that is not part of the table spec (or others) like "owner", and right now there is no way to exchange or share that information. I'm also hesitant to start including it as first-class metadata because that puts additional requirements on catalogs that may not align. For instance, Tabular had no concept of a table "owner" and instead used default grants at the schema level. I like that this solution allows catalogs to provide information in a generic way that doesn't add requirements in the REST spec. And it is an alternative to overriding table properties with catalog-managed information, which I think is an anti-pattern. Thanks, Andrei! I think this is a good idea. On Thu, Mar 5, 2026 at 2:04 PM Andrei Tserakhau via dev < [email protected]> wrote: > Hi all, > > `LoadTableResponse` returns table metadata — schema, snapshots, file > locations — but catalogs have operational context about tables that has no > standard place to go: cost attribution, ownership, governance hints, > semantic metadata. Right now catalogs have two options: > > 1. Properties — durable, commit-versioned table state. Good for persistent > metadata; wrong for ephemeral catalog context. > 2. Custom fields — catalog-specific extensions with no interoperability. > Each catalog invents its own structure; engines have no basis to read them. > > The community has already identified this gap. Polaris opened an issue [1] > requesting a standard extension point in the IRC protocol for > catalog-managed metadata. Two earlier threads [2][3] explored column-level > metadata, though in the context of table format changes. > > We propose adding an optional `labels` field to `LoadTableResponse` for > catalog-managed metadata. Labels are string key-value pairs generated > per-request from the catalog's internal systems; nothing is written to > table files. Engines may use or ignore them entirely. Labels give catalog > providers a standard channel to surface context to any client without > bilateral custom integrations for every catalog-engine pair. > > Details: > - GitHub Issue: apache/iceberg#15521 > - Design Document: [4] > > Please review the proposal and share your feedback. > > Thanks, > Andrei > > [1]: https://github.com/apache/polaris/issues/3222 > [2]: https://lists.apache.org/thread/vwrc3m534gfyfjnsfflwtgkg158yzrb4 > [3]: https://lists.apache.org/thread/yflg8w1h87qgwc4s3qtog4l8nx8nk8m0 > [4]: > https://docs.google.com/document/d/1aj-6JlfBiMYEEVtNuh5WLMOrRQiMCcyYUGbouPM4hXI/edit?usp=sharing >
