+1 (non-binding) On Mon, Apr 20, 2026 at 7:18 AM Russell Spitzer <[email protected]> wrote:
> +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 >> >
