We also have Trino and Hive that support Iceberg views On Tue, Dec 16, 2025 at 4:22 AM Kevin Liu <[email protected]> wrote:
> Thanks for the pointer! I missed the Spark page. Tried it out locally and > wrote some view metadata files. > Looking forward to the PR. > > Best, > Kevin Liu > > > On Mon, Dec 15, 2025 at 6:28 PM Ajantha Bhat <[email protected]> > wrote: > >> 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 >>>>>>>>>>> >>>>>>>>>>
