Pasting Dan's questions from the voting thread > There's actually a more significant discrepancy in that the create/rename/register view can only return a ViewAlreadyExistsError even if it's a table and create/rename/register Table can only return a TableAlreadyExistsError even if it's a view. > I think clarifying the description doesn't really address this issue and functionally we've strictly defined two specific return types that are aligned with their specific load routes, but identifier uniqueness spans multiple.
That is a valid point. We can probably define a new error like `IdentifierAlreadyExistError` with just an error message change, such as "The given identifier already exists." > I also don't know what else may collide (functions, indexes, etc.). Some of this might be engine specific. Most engines/databases seem to treat functions separately. Here is the AI research result. [image: image.png] Regarding index, I was thinking we can revisit once we have more clarify on its design and catalog storage. On Tue, Mar 24, 2026 at 5:57 AM Maximilian Michels <[email protected]> wrote: > +1 for improving the error messages and restricting identifier > uniqueness to tables and views only. We could have also gone with "the > identifier already exists", but this is more nuanced. > > On Tue, Mar 24, 2026 at 10:17 AM Péter Váry <[email protected]> > wrote: > > > > +1 on consistent "Conflict - The identifier already exists as a table or > view" > > > > Steven Wu <[email protected]> ezt írta (időpont: 2026. márc. 24., K, > 6:30): > >> > >> 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" > >> > >> > >> I updated the PR to use the consistent wording "already exists as a > table or view" for the 409 conflict. > >> > >> > >> On Mon, Mar 23, 2026 at 8:30 AM Péter Váry <[email protected]> > wrote: > >>> > >>> We need a `role` paired with the identifier to get the requested > object. The `role` in this case can be the same for tables, views and MVs > >>> > >>> Steven Wu <[email protected]> ezt írta (időpont: 2026. márc. 21., > Szo, 22:08): > >>>> > >>>> > 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: > >>>>>>>> > >>>>>>>> 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." > >>>>>>>> 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 > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Steven >
