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 >> >
