> > are there any engines currently supporting the view spec? Based on my > search, I’m not aware of any. > Hi Kevin, could you clarify what you meant here? The Iceberg View Spec has already been officially approved, and the IRC spec is approved as well. Both Spark (see docs <https://iceberg.apache.org/docs/nightly/spark-ddl/#iceberg-views-in-spark>) and Dremio already support it. Other engine users can comment more on their integration.
It might make sense to prioritize view spec adoption first, so we have more > view metadata JSONs available before adding additional view-related > functionality to the IRC spec. While broader adoption of the view spec would definitely help, I don’t think we should delay adding register view support. Since format version 1 is already standardized and in use, we can always introduce further improvements in format version 2. - Ajantha On Mon, Dec 15, 2025 at 9:32 PM Kevin Liu <[email protected]> wrote: > Hi all, > > Following up on this, are there any engines currently supporting the view > spec? Based on my search, I’m not aware of any. > It might make sense to prioritize view spec adoption first, so we have > more view metadata JSONs available before adding additional view-related > functionality to the IRC spec. > > Thoughts? > > Best regards, > Kevin Liu > > > On Tue, Dec 9, 2025 at 9:57 PM Ajantha Bhat <[email protected]> wrote: > >> 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 >>>>>>>>> >>>>>>>>
