Hi Ajantha, I agree with your approach - register should not change the default-namespace.
When we write the routine in spark, we might want to re-visit the use of `default-namespace` a bit more thoroughly. While it is a required field in the spec, Spark sends an empty array as `default-namespace`. This is against the spec which states that a namespace is a `Reference to one or more levels of a namespace` - not zero. It also creates cross-language problems, as rust is following the spec and returns an error when trying to construct a namespace without 0 elements [1]. Best, Christian [1]: https://github.com/apache/iceberg-rust/blob/7f2dda3a3807e89b162785b4f16d655ca6b84f79/crates/iceberg/src/catalog/mod.rs#L142-L145 On Wed, 7 Jan 2026 at 09:04, Ajantha Bhat <[email protected]> wrote: > Hi Everyone, > > During implementation of register view, observed that view spec > <https://iceberg.apache.org/view-spec/#versions> captures default > namespace. So, once the views are registered from one catalog to another, > *Spark > cannot read that view* as it still points to the old catalog-name as the > default namespace. This problem is specific to spark integration and we had > similar concerns during the spec design. > > I would like to keep the scope of register view limited to just > registering the existing view to the catalog, similar to register table. > For updating or fixing the catalog name, we can provide a separate Spark > procedure. > > I don’t think the register view itself should update the catalog name, > because that would mean creating a new metadata file and a new version, > which is not really a register operation. > > Any thoughts on this? > > - Ajantha > > On Wed, Dec 17, 2025 at 9:11 PM Ajantha Bhat <[email protected]> > wrote: > >> Here are the PRs: >> >> - API,Core: Support registerView for view catalog #14868 >> <https://github.com/apache/iceberg/pull/14868> >> - SPEC: Add REST endpoint for registering views #14869 >> <https://github.com/apache/iceberg/pull/14869> >> - REST: Implement register view for REST catalog #14870 >> <https://github.com/apache/iceberg/pull/14870> >> >> I will open a separate vote thread for spec change, once the spec PR is >> reviewed. >> >> - Ajantha >> >> On Tue, Dec 16, 2025 at 8:52 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 >>>>>>>>>>>>> >>>>>>>>>>>>
