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

Reply via email to