Hi Tobias, If it is an optional field in the request body, that would also be acceptable to me, provided it does not break existing clients.
Regards, JB On Tue, Dec 2, 2025 at 11:33 AM 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 >>>> >>>
