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