+1 (binding) On Wed, May 20, 2026 at 5: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 >
