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