I think it's a good idea to update the spec to show that a conflict could be caused by a table in the view methods or a view in the table methods. I also think it is good to clarify the assumption that tables and views share a namespace, since we are talking about routes that will load either one by name and this is a critical part of that behavior. Before, we didn't have a clear reason to make this a requirement, so I think we left it unspecified.
As for other objects, I don't think that it is a good idea to include functions. To me, those are separate objects that can coexist with the same name as Peter pointed out. And indexes are a bit too early to think about since they may be table-specific and not catalog-tracked objects. On Wed, Mar 25, 2026 at 7:55 AM Daniel Weeks <[email protected]> wrote: > I would just add that this issue is largely isolated to the spec > definition and likely has little impact on the implementations. > > The various conflict responses (TableAlreadyExistsError, > ViewAlreadyExistsError, etc.) are all just slightly different flavors of > 409 CONFLICT that we send back to the client. The only practical > difference is the text we send back. > > If we wanted to formalize the right response for the conflicting object > (not based on which route was used), we could change the responses to > "oneOf" and the spec would allow for representing the conflict accurately. > In practice, I think this is what some catalog implementations already do. > > -Dan > > On Tue, Mar 24, 2026 at 1:22 PM Steven Wu <[email protected]> wrote: > >> 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 >>> >>
