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