+1 binding On Thu, May 21, 2026, 04:15 roryqi <[email protected]> wrote:
> +1 (non-binding) > > Neelesh Salian <[email protected]> 于2026年5月21日周四 07:48写道： > > > > +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 >
