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 >
