+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 >>> >>
