> Do we really want to prevent creating a `rank` function if we already have a table named `rank`?
This is a good argument. I agree functions can be in a separate dimension. Earlier, I was thinking from the perspective of a universal batch load endpoint, where a client may send one catalog request for all referenced objects (tables, views, MVs, functions). We can still make it work if functions are separated out in the batch load request. Or we can limit the universal batch load endpoint to tables, views, and MVs only. Clients may not need to load index objects separately. They can be piggybacked during table loading. On Sat, Mar 21, 2026 at 12:38 AM Péter Váry <[email protected]> wrote: > I think we definitely should discuss the global uniqueness in details. > > Do we really want to prevent creating a `rank` function if we already have > a table named `rank`? > > I'm fully on board to avoid having the same name for a table and a view, > as they are fully interchangeable, but functions and indexes could use the > same name and the engines could decide which one to use based on the > context. > > So I think we need to seriously consider if we want to propose > restrictions like this. > > WDYT? > > > On Fri, Mar 20, 2026, 15:19 Steven Wu <[email protected]> wrote: > >> Hi Peter, >> >> I can understand the hesitation, especially considering the new >> *CatalogObjectType *not used by the spec (except for the references in >> the description text). >> >> I added it in this PR for the following reasons: >> * Huaxin has a PR for functions [1], which will introduce a new function >> object type in the catalog. I believe we want to enforce uniqueness across >> all types: tables, views, and functions. >> * index proposal also discussed the index object type in the catalog. but >> this is a bit farther away. >> * Events endpoint proposal also needs to introduce the >> *CatalogObjectType *concept [2, 3]. >> >> I am ok with removing it from this PR. We can add it later, perhaps, in >> the events or function endpoint spec change. >> >> Thanks, >> Steven >> >> [1] Function endpoint spec: https://github.com/apache/iceberg/pull/15180 >> [2] Events endpoint spec: https://github.com/apache/iceberg/pull/12584 >> [3] Events endpoint impl: https://github.com/apache/iceberg/pull/14142 >> >> >> >> On Fri, Mar 20, 2026 at 3:00 AM Péter Váry <[email protected]> >> wrote: >> >>> Hi Steven, >>> I completely agree that we should align the uniqueness requirements >>> between table and view creation. >>> I’m a bit hesitant about introducing *CatalogObjectType*. It makes >>> sense if we expect to add more object types and want to enforce uniqueness >>> across them, but I’m not sure we need that level of generality yet. Do you >>> have something specific in mind that would require it? >>> Thanks, >>> Peter >>> >>> Steven Wu <[email protected]> ezt írta (időpont: 2026. márc. 19., >>> Cs, 21:17): >>> >>>> Hi all, >>>> >>>> I'd like to discuss a minor inconsistency in the REST Catalog >>>> specification regarding identifier uniqueness within a namespace. >>>> >>>> *Background: Inconsistency in Conflict Descriptions* >>>> >>>> The REST spec currently defines six write operations that return a 409 >>>> Conflict when an identifier already exists: createTable, registerTable >>>> , renameTable, createView, renameView, and registerView. >>>> >>>> However, the descriptions for *what* constitutes a conflict are not >>>> consistent: >>>> >>>> - *Enforcing cross-type uniqueness* (table or view): >>>> - renameTable, renameView, registerView say: *"already exists as >>>> a table or view"* >>>> - *Only enforcing within the same type* (table or view only): >>>> - createTable, registerTable, createView say: *"table already >>>> exists"* / *"view already exists"* >>>> >>>> This ambiguity leaves it unclear whether a catalog is allowed to have a >>>> table and a view with the same name in the same namespace. >>>> >>>> *Proposed Change* >>>> >>>> I believe the intent is that identifiers *must* be unique across all >>>> catalog object types within the same namespace (otherwise the rename >>>> operations become impossible to reason about). >>>> >>>> The proposed change makes this explicit in two ways: >>>> >>>> 1. *New CatalogObjectType schema:* Enumerates the known catalog >>>> object types (table, view) and states the uniqueness invariant: >>>> *"Identifiers >>>> MUST be unique across all catalog object types within the same >>>> namespace; a >>>> table and a view with the same name in the same namespace are not >>>> allowed."* >>>> 2. *Consistent 409 descriptions:* All six write operations will now >>>> reference CatalogObjectType and use uniform language: *"The >>>> identifier is already used by an existing catalog object (see >>>> CatalogObjectType)"* >>>> >>>> This change is purely spec-clarification; it introduces no new behavior >>>> for catalogs that already enforce cross-type uniqueness. >>>> >>>> The proposed clarification is available here: >>>> https://github.com/apache/iceberg/pull/15691 >>>> <https://www.google.com/url?source=gmail&sa=E&q=https://github.com/stevenzwu/iceberg/tree/rest-spec-clarify-id-conflict-requirement> >>>> >>>> Thanks, >>>> Steven >>>> >>>
