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 >
