Re: [Discuss] Support for register view

[Ajantha Bhat]

>
> - API,Core: Support registerView for view catalog #14868
> - SPEC: Add REST endpoint for registering views #14869
> - Core: Add RegisterViewRequest, parser, and serializers #15068
> - Core: Implement register view for REST catalog #14870


Thanks everyone. All the required implementation PRs mentioned above have
been merged.
The Register View feature will be available in the next release.
Next, I’ll focus on the Repair View procedure for Spark, as discussed in
the thread above.

- Ajantha

On Thu, Jan 8, 2026 at 10:46 AM Ajantha Bhat  wrote:

> Thanks Steven. This is a very nice point.
>
>> The default catalog could also mean a 3rd catalog
>
>
> Overall, I think we all agree that the register view should only register
> the existing metadata. If the view is not queryable in the new catalog from
> Spark (due to the current spec design and how it is integrated with Spark),
> we can provide a Spark procedure to fix it.
>
> Ideally, we should avoid requiring users to do manual maintenance (such as
> running a procedure). It would be good to revisit the view spec from an
> interoperability perspective and see whether Spark integration for views
> can be handled differently to improve interoperability and update the spec
> accordingly if required (maybe version 2).
> - Ajantha
>
>
> On Wed, Jan 7, 2026 at 11:47 PM Steven Wu  wrote:
>
>> 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 
>> 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
>>>  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 
>>> 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 
>>> wrote:
>>> >>>
>>> >>> Here are the PRs:
>>> >>>
>>> >>> - API,Core: Support registerView fo

Re: [Discuss] Support for register view

[Ajantha Bhat]

Thanks Steven. This is a very nice point.

> The default catalog could also mean a 3rd catalog


Overall, I think we all agree that the register view should only register
the existing metadata. If the view is not queryable in the new catalog from
Spark (due to the current spec design and how it is integrated with Spark),
we can provide a Spark procedure to fix it.

Ideally, we should avoid requiring users to do manual maintenance (such as
running a procedure). It would be good to revisit the view spec from an
interoperability perspective and see whether Spark integration for views
can be handled differently to improve interoperability and update the spec
accordingly if required (maybe version 2).
- Ajantha


On Wed, Jan 7, 2026 at 11:47 PM Steven Wu  wrote:

> 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  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
>>  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 
>> 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 
>> 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 
>> 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 
>> wrote:
>> >>
>> >> are there any engines currently supp

Re: [Discuss] Support for register view

[Steven Wu]

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  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
>  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  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 
> 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 
> 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 
> 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

Re: [Discuss] Support for register view

[Ajantha Bhat]

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
 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  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  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  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  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  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  
>> 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  wrote:

 That's a good point, Gabor. Catalog servers advertise view support 
 through the getConfig (v1/config) response. So a de

Re: [Discuss] Support for register view

[Christian Thiel]

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  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 
> 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  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 
>>> 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 
 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 
> 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 
>> 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)
>>

Re: [Discuss] Support for register view

[Ajantha Bhat]

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  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  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 
>> 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  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 
 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 
> 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 
>> 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é  ezt írta (időpont: 2025.
>>> dec. 2., K, 15:09):
>>>
 Hi Tobias,

Re: [Discuss] Support for register view

[Ajantha Bhat]

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  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 
> 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  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 
>>> 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 
 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 
> 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é  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 
>>> 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é <
 j...@nanthrax.net>:

> 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
>
> 

Re: [Discuss] Support for register view

[Eduard Tudenhöfner]

We also have Trino and Hive that support Iceberg views

On Tue, Dec 16, 2025 at 4:22 AM Kevin Liu  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 
> 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  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 
>>> 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 
 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 
> 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é  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 
>>> 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é <
 j...@nanthrax.net>:

> 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 
> 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,

Re: [Discuss] Support for register view

[Kevin Liu]

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  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  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 
>> 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  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 
 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é  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 
>> 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é <
>>> j...@nanthrax.net>:
>>>
 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 
 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 separ

Re: [Discuss] Support for register view

[Ajantha Bhat]

>
> 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  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  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  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 
>>> 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é  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 
> 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é <
>> j...@nanthrax.net>:
>>
>>> 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 
>>> 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 
 wrote:

Re: [Discuss] Support for register view

[Kevin Liu]

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  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  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 
>> 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é  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 
 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é <
> j...@nanthrax.net>:
>
>> 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 
>> 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 
>>> 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 

Re: [Discuss] Support for register view

[Ajantha Bhat]

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  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 
> 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é  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 
>>> 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é <
 j...@nanthrax.net>:

> 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 
> 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 
>> 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.
>>>
>>> - Aja

Re: [Discuss] Support for register view

[Kevin Liu]

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  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é  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 
>> 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é <
>>> j...@nanthrax.net>:
>>>
 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  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 
> 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
>>
>

Re: [Discuss] Support for register view

[Gábor Kaszab]

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é  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  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é <
>> j...@nanthrax.net>:
>>
>>> 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  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 
 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
>

Re: [Discuss] Support for register view

[Jean-Baptiste Onofré]

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  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é <
> j...@nanthrax.net>:
>
>> 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  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 
>>> 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

>>>

Re: [Discuss] Support for register view

[Ajantha Bhat]

Thanks Kevin for the response.

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.


I didn't go into full implementation details previously as I wanted to
discuss the solution first. I was hoping to add a new endpoint
/v1/{prefix}/namespaces/{namespace}/register-view and use the existing
LoadViewResponse on success.
I think we should leave the corresponding register endpoint (used for
tables) untouched to avoid breaking compatibility and to provide separate
authorization for registering views.

- Ajantha


On Tue, Dec 2, 2025 at 4:04 PM Tobias  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é <
> j...@nanthrax.net>:
>
>> 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  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 
>>> 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

>>>

Re: [Discuss] Support for register view

[Tobias]

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é <
j...@nanthrax.net>:

> 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  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 
>> 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
>>>
>>

Re: [Discuss] Support for register view

[Jean-Baptiste Onofré]

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  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 
> 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
>>
>

Re: [Discuss] Support for register view

[Kevin Liu]

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  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
>