I'm also in favor of a new endpoint. REST API spec clearly supports the `purgeRequested` > <https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml#L1154> > parameter > in the drop table. So, server implementations must honor it and not > remove files when it is not set? Can you please elaborate why you think "we > need a way to prevent files from being removed"?
To clarify and differentiate this from the drop+purge behavior, the `purgeRequested` flag requests that the server immediately delete the data. Setting it to false does not require the server to preserve the data, but rather allows for the data to be cleaned up at a later time. These are also not required behaviors of the catalog implementation as the server my ignore or provide its own behavior around table management. Introducing an 'unregister' has its own expected behavior distinct from drop+purge targeted specifically at detaching management of the data from the catalog. -Dan On Tue, May 19, 2026 at 11:21 AM Neelesh Salian <[email protected]> wrote: > +1 as well. > > On Tue, May 19, 2026 at 11:07 AM Steven Wu <[email protected]> wrote: > >> +1 on the new endpoint >> >> On Tue, May 19, 2026 at 10:57 AM Amogh Jahagirdar <[email protected]> >> wrote: >> >>> +1 from me, just had a comment on some of the wording in the spec. >>> >>> On Tue, May 19, 2026 at 11:38 AM Yufei Gu <[email protected]> wrote: >>> >>>> +1 on the new endpoint. I agree that concurrent writes are the >>>> sticky part where we cannot safely use the drop endpoint. >>>> >>>> Yufei >>>> >>>> >>>> On Tue, May 19, 2026 at 5:57 AM Jean-Baptiste Onofré <[email protected]> >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> It sounds like "logic" to me. Today the catalogs are dealing with that >>>>> "specifically". So something in the spec makes sense. >>>>> >>>>> Regards >>>>> JB >>>>> >>>>> On Mon, May 18, 2026 at 10:50 PM Ryan Blue <[email protected]> wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I just opened a PR to add an `unregister` endpoint to the REST spec, >>>>>> #16400 <https://github.com/apache/iceberg/pull/16400>. Unregister is >>>>>> the opposite of `register` and allows you to remove a table from a >>>>>> catalog >>>>>> without deleting its underlying data and metadata files. The purpose is >>>>>> to >>>>>> allow moving from one catalog to another. >>>>>> >>>>>> I think it was just an oversight that we didn't already have this. I >>>>>> know that we've talked about adding a way to unregister a table in the >>>>>> past, but I didn't see a previous email thread so I thought I'd start >>>>>> this >>>>>> one. We originally assumed that the drop table endpoint would work, but >>>>>> we >>>>>> need a different one for two reasons. First, most REST catalogs take care >>>>>> of table cleanup (rather than putting the responsibility on the user or >>>>>> engine at the time DROP is run) and we need a way to prevent files from >>>>>> being removed. Second, DROP doesn't work for concurrent operations. We >>>>>> need >>>>>> to return the current table state and metadata location from the >>>>>> `unregister` operation and have the assurance that it is the latest state >>>>>> from the catalog and that any other operations against the table will >>>>>> fail. >>>>>> >>>>>> Please take a look and reply. If there aren't many objections, I'll >>>>>> try to start a vote thread sometime this week. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Ryan >>>>>> >>>>>
