+1 on the new endpoint for the stated use case
On Tue, May 19, 2026 at 11:39 AM Daniel Weeks <[email protected]> wrote: > > I'm also in favor of a new endpoint. > >> REST API spec clearly supports the `purgeRequested` 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. 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
