I think Option A is a clean solution and I’d prefer to go with it. However, there are backward compatibility concerns, especially for the events endpoint[1], where we are trying to use a unified identifier to represent all object types. I’m not sure there’s a clean way to apply Option A in the current event spec. One possible approach is to allow both representations for existing entities like tables and views, so that Option A and Option B can coexist.
1. https://github.com/apache/iceberg/pull/12584/changes#r3024014158 Yufei On Thu, Apr 23, 2026 at 2:27 PM Steven Wu <[email protected]> wrote: > Thanks Christian, Ryan, Dan for the comments in the doc. There seems to be > no objection to the generic identifier concept. However, there is one > central open question regarding the identifier structure: (A) a flat list > of level (B) current table identifier tuple pattern of (namespace, name) > > > https://docs.google.com/document/d/1NTQhgNbP2dkIMuXUMA5JdwliVQKCp1TU_ux5J_AaPiw/edit?disco=AAAB33pnNqQ > > > On Sat, Apr 11, 2026 at 12:24 PM Christian Thiel < > [email protected]> wrote: > >> Thanks for the nice write-up, Steven — with all the use cases converging >> on this, it's a good moment to settle on a notation. >> I've added my thoughts in the doc. Happy to discuss in one of the >> upcoming syncs! >> >> Best, >> Christian >> >> On Wed, 1 Apr 2026 at 14:47, Steven Wu <[email protected]> wrote: >> >>> Hi, >>> >>> I like to discuss a proposal to introduce a generic >>> CatalogObjectIdentifier >>> <https://docs.google.com/document/d/1NTQhgNbP2dkIMuXUMA5JdwliVQKCp1TU_ux5J_AaPiw/edit?tab=t.0> >>> . >>> >>> The Iceberg REST catalog spec currently defines a single TableIdentifier >>> schema as a (namespace, name) tuple. This identifier is used for both >>> tables and views throughout the spec, which is semantically inaccurate for >>> view objects and does not generalize to other catalog object types. >>> >>> Several concurrent efforts have independently surfaced the need for a >>> generic catalog object identifier: >>> >>> - >>> >>> Events endpoint ( >>> >>> <https://github.com/apache/iceberg/pull/12584/changes#diff-02549ca620d020dc9ead80088cc14e311e12a69651fa8d394cd41a4308debb2e>PR >>> #12584 >>> <https://github.com/apache/iceberg/pull/12584/changes#r3024014158>): >>> The spec introduced a CatalogObjectIdentifier to reference any catalog >>> object in event payloads, including namespaces, tables, and views. >>> - >>> >>> Function endpoints (PR #15180 >>> <https://github.com/apache/iceberg/pull/15180>): The list/load >>> function spec needs identifiers for function objects. A comment suggests >>> using a generic CatalogObjectIdentifier instead of a function-specific >>> one. >>> - >>> >>> Universal relation load (PR #15830 >>> <https://github.com/apache/iceberg/pull/15830>): The batch load >>> endpoint for tables and views introduced CatalogObjectType as a >>> discriminator, which pairs naturally with a generic identifier. >>> >>> >>> As Iceberg evolves to support more object types — functions, indices — >>> each will need catalog identifiers. Defining a single reusable schema now >>> avoids type proliferation and naming confusion. >>> >>> Thanks, >>> Steven >>> >>
