Thanks Kevin for the response.
The `registerView` function makes sense to me. The IRC spec, however, might
> be a bit more complicated. The "register" endpoint
> (`/v1/{prefix}/namespaces/{namespace}/register`) [1] is currently used to
> register tables only. We could either extend this endpoint to support views
> or create a separate "registerView" endpoint.
I didn't go into full implementation details previously as I wanted to
discuss the solution first. I was hoping to add a new endpoint
/v1/{prefix}/namespaces/{namespace}/register-view and use the existing
LoadViewResponse on success.
I think we should leave the corresponding register endpoint (used for
tables) untouched to avoid breaking compatibility and to provide separate
authorization for registering views.
- Ajantha
On Tue, Dec 2, 2025 at 4:04 PM Tobias <[email protected]> wrote:
> Hi,
>
> What speaks against making /register first try the provided metadata as a
> table and then as a view before rejecting as invalid?
>
> @JB, why would you prefer a header param over an optional field `type` in
> the request?
>
> Kind regards,
> Tobias
>
> Am Di., 2. Dez. 2025 um 07:45 Uhr schrieb Jean-Baptiste Onofré <
> [email protected]>:
>
>> Hi
>>
>> I agree that registerView makes sense.
>>
>> Regarding the /register endpoint in the IRC spec, maybe we can use a
>> header param (optional) when we want to register a view (view=true for
>> instance).
>>
>> Regards
>> JB
>>
>> On Tue, Dec 2, 2025 at 5:12 AM Kevin Liu <[email protected]> wrote:
>>
>>> Hi Ajantha,
>>>
>>> Thanks for bringing this up. I think it's a good idea to be able to
>>> register views, and by extension, to replicate from one catalog to another.
>>>
>>> The `registerView` function makes sense to me. The IRC spec, however,
>>> might be a bit more complicated. The "register" endpoint
>>> (`/v1/{prefix}/namespaces/{namespace}/register`) [1] is currently used to
>>> register tables only. We could either extend this endpoint to support views
>>> or create a separate "registerView" endpoint.
>>>
>>> Would love to hear what others think.
>>>
>>> Best,
>>> Kevin Liu
>>>
>>> [1]
>>> https://github.com/apache/iceberg/blob/b35c7ec1b03e3897da68960cd556d635b2f5ae54/open-api/rest-catalog-open-api.yaml#L868
>>>
>>> On Tue, Nov 25, 2025 at 2:28 AM Ajantha Bhat <[email protected]>
>>> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> Currently, catalogs provide a *registerTable* function that allows
>>>> registering an existing table with a catalog if it does not already exist.
>>>> This is particularly useful for migrating Iceberg tables between catalogs.
>>>>
>>>> We have users who are in the process of migrating from one catalog to
>>>> another. While migrating tables works well, migrating *views* remains
>>>> challenging. One option is to simply recreate the views, since view
>>>> creation is a lightweight operation. However, this approach has two main
>>>> drawbacks:
>>>>
>>>> -
>>>>
>>>> Recreating a view loses its version history and original metadata.
>>>> -
>>>>
>>>> Some catalogs may not allow recreating a view if a view with the
>>>> same name already exists in the target location.
>>>>
>>>> To address this, I propose adding a *registerView* functionality for
>>>> completeness. This would enable users to register existing views with a
>>>> catalog, similar to how we register existing tables today.
>>>>
>>>> As a follow-up, I can open a PR to implement:
>>>>
>>>> -
>>>>
>>>> registerView(TableIdentifier identifier, String
>>>> metadataFileLocation) in ViewCatalog
>>>> -
>>>>
>>>> Corresponding updates to the Iceberg REST catalog spec
>>>> -
>>>>
>>>> Necessary API additions
>>>>
>>>> Would love to hear your thoughts and feedback on this proposal.
>>>>
>>>> - Ajantha
>>>>
>>>
