With 16 +1 votes (9 binding / 7 non-binding) and no +0 or -1 votes, this passes. Thanks, everyone!
Ryan On Thu, May 21, 2026 at 12:29 PM Daniel Weeks <[email protected]> wrote: > +1 (binding) > > On Wed, May 20, 2026 at 11:36 PM Maninder Parmar < > [email protected]> wrote: > >> +1 (non-binding) as it defines clearer semantics about data lifecycle >> >> On Thu, May 21, 2026, 8:23 AM Eduard Tudenhöfner < >> [email protected]> wrote: >> >>> +1 (binding) >>> >>> On Thu, May 21, 2026 at 8:13 AM Gang Wu <[email protected]> wrote: >>> >>>> +1 (non-binding) >>>> >>>> On Thu, May 21, 2026 at 1:13 PM Péter Váry <[email protected]> >>>> wrote: >>>> > >>>> > +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 >>>> >>>
