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