For the following reasons, I am also in favor that registerView doesn't automatically modify the `default-catalog` field from the source catalog to the destination catalog
* There is a major difference between registerTable and registerView. A table is fully self-contained. A view always references other tables or views. If the referenced source views and tables haven't been migrated before the registerView, it is not safe to auto update the catalog name. * The default catalog could also mean a 3rd catalog. In this case, we certainly don't want to change the field value. But I guess we can potentially compare the values to detect this scenario. * In the MV discussion, there was an extensive debate on the catalog name. Different setups can use different names for the same catalog, which is totally a setup problem that Iceberg view spec can't guard against. On Wed, Jan 7, 2026 at 8:58 AM Ajantha Bhat <[email protected]> wrote: > Hi all, I meant the registered view in the new catalog uses the > `default-catalog` as the old catalog name. Which inturn causes the > failure to read the view in Spark. So, the discussion was about > catalog names. Should we update it during register view or from a > separate procedure. I am in favour of separate procedures. > > And thanks Christian for bringing up the java implementation issue > with `default-namespace` (another field in the spec). We will check if > the new procedure can also fix that in the existing views and new > views from Spark can avoid writing like that. > > - Ajantha > > > On Wed, Jan 7, 2026 at 10:08 PM Christian Thiel > <[email protected]> wrote: > > > > 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 > 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 > >>> - SPEC: Add REST endpoint for registering views #14869 > >>> - REST: Implement register view for REST catalog #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) 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 >
