Hi Yufei, While deriving default storage locations from the namespace hierarchy can be convenient for some users, I do not think strict nestig can be assumed in all cases.
Fundamentally namespaces govern table names. I believe users may still want tables to be stored in locations that do not follow namespace nesting. Cheers, Dmitri. On Mon, Aug 31, 2026 at 5:26 PM Yufei Gu <[email protected]> wrote: > Hi folks, > > I’d like to clarify the intended behavior of > ALLOW_NAMESPACE_CUSTOM_LOCATION. > > Today, when it's true, Polaris skips parent-location validation, so a > namespace can be created anywhere, not just at a custom location under its > parent. The name does not make this “arbitrary location” behavior obvious, > which is confusing. Users may consider different cases, such as creating a > custom location under the parent. Most repository uses appear to be for > tests, though the setting is externally configurable and downstream users > may rely on it. > > I think the more useful behavior would be to allow caller-specified > locations while keeping them within the parent’s storage boundary: > > 1. Top-level namespaces must stay within the catalog’s default base > location. > 2. Nested namespaces must stay within their parent namespace. > 3. Existing overlap checks still apply. > > Changing the flag’s behavior could break use cases relying on locations > outside the parent, but I'm less concerned as it's mainly used for tests > now. I'd still like feedback on these points: > > 1. Should we change the existing flag or introduce a new > constrained-location setting? > 2. Are there known non-test use cases for completely arbitrary namespace > locations? > > Yufei >
