+1 (non-binding). PR looks good. Thanks Ryan. On Wed, May 20, 2026 at 4:45 PM Kevin Liu <[email protected]> wrote:
> +1 (binding) > thanks! > > On Wed, May 20, 2026 at 4:23 PM Steven Wu <[email protected]> wrote: > >> +1 (binding) >> >> On Wed, May 20, 2026 at 4:15 PM Steve <[email protected]> wrote: >> >>> +1 (non-binding) >>> >>> On Wed, May 20, 2026 at 2:41 PM Alexandre Dutra <[email protected]> >>> wrote: >>> > >>> > +1 (non-binding), this will be useful for catalog migration scenarios. >>> > >>> > Thanks, >>> > Alex >>> > >>> > On Wed, May 20, 2026 at 10:40 PM Ryan Blue <[email protected]> wrote: >>> > > >>> > > +1 >>> > > >>> > > On Wed, May 20, 2026 at 1:39 PM Russell Spitzer < >>> [email protected]> wrote: >>> > >> >>> > >> +1 >>> > >> >>> > >> On Wed, May 20, 2026 at 3:37 PM Ryan Blue <[email protected]> wrote: >>> > >>> >>> > >>> Hi everyone, >>> > >>> >>> > >>> I think that there is general agreement for adding an `unregister` >>> endpoint to the REST spec, so I'd like to vote on the addition. The PR is >>> #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. This >>> requires a new endpoint because the underlying table data and metadata >>> files should be left in place, and the latest catalog state of the table >>> should be returned. >>> > >>> >>> > >>> Please vote in the next 72 hours, >>> > >>> >>> > >>> [ ] +1: Add unregister to the REST spec >>> > >>> [ ] +0: Note a non-blocking concern . . . >>> > >>> [ ] -1: Do not add unregister because . . . >>> > >>> >>> > >>> Thanks, >>> > >>> >>> > >>> Ryan >>> >>
