Thanks everyone. As there are no additional comments on the proposed solution, I’ll move forward with the implementation and share the corresponding PRs when they’re ready.
- Ajantha On Tue, Dec 2, 2025 at 10:42 PM Kevin Liu <[email protected]> wrote: > 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 >>>>>>> >>>>>>
