+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
