+1 We need this! Thanks Ryan for taking care of this! Ajantha Bhat <[email protected]> ezt írta (időpont: 2026. máj. 19., K, 6:11):
> 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 >>> >>
