Hi Ryan, 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.
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"? Also, in the implementation I see an open issue <https://github.com/apache/iceberg/issues/14743> related to this flag. Should we fix this issue first? 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. Strongly agree with this. While working on Iceberg catalog migrator, <https://github.com/apache/polaris-tools/tree/main/iceberg-catalog-migrator> we have warned the users that we shouldn't migrate during inprogress commits. Using the metadata location output after unregister will make things atomic and avoid this issue. I can update my code to use this endpoint. *So, I am generally +1 on this. *While we are at it, should we also add unregister-view for the sake of completion? as we have a register-view <https://github.com/apache/iceberg/pull/14869> endpoint now. I am happy to add an unregister-view endpoint if we agree on this. - Ajantha On Tue, May 19, 2026 at 3:16 AM Russell Spitzer <[email protected]> wrote: > +1, I think I brought this up a few times and was too lazy to actually > start a thread. I think this also pretty clearly ties up the "portability" > story between catalogs. > > On Mon, May 18, 2026 at 3:49 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 >> >
