+1 On Mon, Apr 20, 2026 at 9:16 AM Alexandre Dutra <[email protected]> wrote:
> +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 >
