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