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
