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