That's a good point, Gabor. Catalog servers advertise view support through the getConfig (v1/config) response. So a dedicated register view endpoint is more explicit. This way also provides separate authz for registerView, as Ajantha mentioned. I like this method.
Just to recap on the above. The 2 other ideas are - overload the /register endpoint to support view, using an optional header param (i.e. view=true) - overload the /register endpoint to support view; try as table first, then fallback to view (similar to the loadTable behavior) Best, Kevin Liu On Tue, Dec 2, 2025 at 6:56 AM Gábor Kaszab <[email protected]> wrote: > Hey All, > > +1 for the improvement in general. > Also, I think it makes sense to make a distinction between table endpoints > and view endpoints instead of making the register endpoint more general. > The server could articulate explicitly if such a register view endpoint is > supported or not when returning the list of supported endpoints. If we > change the register endpoint to serve both, we won't be able to decide > simply by looking at the list of endpoints if the server is able to > register views or not. > So +1 for a new endpoint. > > Cheers, > Gabor > > Jean-Baptiste Onofré <[email protected]> ezt írta (időpont: 2025. dec. 2., > K, 15:09): > >> 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 >>>>>> >>>>>
