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