+1 (non-binding)
On Mon, Apr 20, 2026 at 10:02 AM Maximilian Michels <[email protected]> wrote: > > +1 (non-binding) > > On Mon, Apr 20, 2026 at 8:37 AM Eduard Tudenhöfner > <[email protected]> wrote: > > > > +1 > > > > On Sat, Apr 18, 2026 at 8:39 AM Péter Váry <[email protected]> > > wrote: > >> > >> +1 > >> > >> On Sat, Apr 18, 2026, 03:28 Neelesh Salian <[email protected]> > >> wrote: > >>> > >>> +1 (non-binding). Thanks Steven. > >>> > >>> On Fri, Apr 17, 2026 at 18:23 John Zhuge <[email protected]> wrote: > >>>> > >>>> +1 (non-binding) > >>>> > >>>> On Fri, Apr 17, 2026 at 12:28 PM Yufei Gu <[email protected]> wrote: > >>>>> > >>>>> +1 binding > >>>>> > >>>>> Thanks Steven for the change. Hopefully there is no downstream clients > >>>>> building logic based on the error message. > >>>>> > >>>>> Yufei > >>>>> > >>>>> > >>>>> On Fri, Apr 17, 2026 at 12:22 PM Kevin Liu <[email protected]> > >>>>> wrote: > >>>>>> > >>>>>> +1 binding > >>>>>> > >>>>>> Thanks Steven! > >>>>>> > >>>>>> On Fri, Apr 17, 2026 at 11:54 AM Daniel Weeks <[email protected]> > >>>>>> wrote: > >>>>>>> > >>>>>>> I followed up with Steven offline and with the updates I'm changing > >>>>>>> my vote to a +1. > >>>>>>> > >>>>>>> Thanks Steven! > >>>>>>> > >>>>>>> On Tue, Mar 24, 2026 at 12:49 PM Daniel Weeks <[email protected]> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> -1 (for now) > >>>>>>>> > >>>>>>>> Steven, I'm not sure we've had enough discussion on this and what > >>>>>>>> we're actually trying to solve for. The PR looks like we're just > >>>>>>>> updating the description, but there's really no functional change > >>>>>>>> here. > >>>>>>>> > >>>>>>>> There's actually a more significant discrepancy in that the > >>>>>>>> create/rename/register view can only return a ViewAlreadyExistsError > >>>>>>>> even if it's a table and create/rename/register Table can only > >>>>>>>> return a TableAlreadyExistsError even if it's a view. > >>>>>>>> > >>>>>>>> I think clarifying the description doesn't really address this issue > >>>>>>>> and functionally we've strictly defined two specific return types > >>>>>>>> that are aligned with their specific load routes, but identifier > >>>>>>>> uniqueness spans multiple. > >>>>>>>> > >>>>>>>> I also don't know what else may collide (functions, indexes, etc.). > >>>>>>>> Some of this might be engine specific. > >>>>>>>> > >>>>>>>> I just don't feel like this is the right way to address it (though I > >>>>>>>> could be convinced otherwise if there something specific we need to > >>>>>>>> solve in the near term). > >>>>>>>> > >>>>>>>> -Dan > >>>>>>>> > >>>>>>>> On Tue, Mar 24, 2026 at 11:09 AM Steven Wu <[email protected]> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi. > >>>>>>>>> > >>>>>>>>> The REST spec currently defines six write operations that return a > >>>>>>>>> 409 Conflict when an identifier already exists. However, the > >>>>>>>>> descriptions of what constitutes a conflict are inconsistent: > >>>>>>>>> > >>>>>>>>> Enforcing cross-type uniqueness (table or view): > >>>>>>>>> > >>>>>>>>> renameTable, renameView, registerView say: "already exists as a > >>>>>>>>> table or view" > >>>>>>>>> > >>>>>>>>> Only enforcing within the same type (table or view only): > >>>>>>>>> > >>>>>>>>> createTable, registerTable, createView say: "table already exists" > >>>>>>>>> / "view already exists" > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I'd like to propose a vote on a small clarification in the REST > >>>>>>>>> spec to apply the same wording of "The identifier already exists as > >>>>>>>>> a table or view" across all 6 endpoints. > >>>>>>>>> > >>>>>>>>> https://github.com/apache/iceberg/pull/15691/changes > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Steven > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>> > >>>> > >>>> -- > >>>> John Zhuge
