yeah, I meant  PR15691. Thanks for catching the wrong url, Kevin!

On Fri, Apr 24, 2026 at 10:23 AM Kevin Liu <[email protected]> wrote:

> Just to clarify, I think you meant
> https://github.com/apache/iceberg/pull/15691 which is now merged.
>
> On Wed, Apr 22, 2026 at 9:57 PM Steven Wu <[email protected]> wrote:
>
>> The vote passed with 11 +1s (6 binding and 5 non-binding) and no -1.
>>
>> I will merge the spec PR that fixes the inconsistent wording.
>> https://github.com/apache/iceberg/pull/15830
>>
>> Thanks everyone for the review and vote.
>>
>>
>> On Mon, Apr 20, 2026 at 7:24 AM huaxin gao <[email protected]>
>> wrote:
>>
>>> +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
>>>>>
>>>>

Reply via email to