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