Hi All, I added optional UUID to the REST Spec based on our discussion at Catalog Sync. I am happy to get your reviews :)
https://github.com/apache/iceberg/pull/15317 Talat On Tue, Jan 13, 2026 at 12:42 PM Daniel Weeks <[email protected]> wrote: > Hey Talat, > > I can understand the motivation for wanting an identifier for a namespace, > but I'm not sure what requirements we are expecting to place on clients or > servers in relation to this. I believe many REST implementations (and some > non-rest) internally track namespaces through some sort of internal > identifier. This allows policy and enforcement to follow that identifier > without exposing it to clients. I'm not sure I agree that this is > equivalent to "drop-and-create" as the server implementation can maintain > all references/context through the operation. > > There is a narrow case where a namespace rename/drop could have a race > condition and the wrong entity is dropped/relocated, but it doesn't sound > like that is the primary motivation. While this is theoretically a > problem, in practice it hasn't really been a problem because there isn't as > much contention with these operations as there are with table > create/commit/drop (which is why all of those operations include uuid > validation). > > I feel like in a perfect world, you would be able identify all resource by > some unique identifier, but many of the original catalog implementations > either didn't have the ability to track this (e.g. some don't even support > namespace properties or have a physical representation for the namespace) > or the catalogs/clients didn't support the concept of renaming/moving > namespaces (many still don't). > > I think it would help to enumerate the expectations of the client since I > believe servers can manage most of this independent from the spec > definition. > > -Dan > > > > On Tue, Jan 13, 2026 at 9:02 AM Talat Uyarer via dev < > [email protected]> wrote: > >> Hi everyone, >> >> I would like to start a discussion regarding a proposed enhancement to >> the Iceberg REST Catalog Specification: adding an optional, fixed UUID >> field to the Namespace object. >> Currently, our REST specification identifies Namespaces by their path (a >> tuple of strings). While sufficient for basic navigation, this creates >> significant challenges for security and catalog management. >> >> In managed environments (such as BigLake), IAM policies are often >> attached at the Namespace level. We face a "name reuse" risk: if Namespace >> A is deleted and recreated, a system relying solely on the name might >> incorrectly apply "stale" permissions from the old resource to the new one. >> UUID is required to distinguish the identity of a resource from its name. >> >> Beyond security, I also saw there was a ticket for Namespace Renaming [1] >> and outlined in this design doc. >> >> We often use UUID for tables and views to decouple renaming in Apache >> Iceberg. Supporting a rename operation becomes significantly more robust if >> the namespace has a stable UUID. Without it, a rename is essentially a >> "delete-and-create" from the perspective of external observers (governance >> tools, IAM, or cached metadata). A fixed UUID allows us to decouple the >> identity of the namespace from its current label, ensuring that policies >> and lineage remain intact even after a rename. >> >> I would like to hear your thoughts about this issue. >> >> Talat >> >> [1] https://github.com/apache/iceberg/issues/13023 >> >
