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

Reply via email to