+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
