I'm in favor of this. I think it's much safer to take determinism out of table creation and location.
On Mon, Jun 8, 2026 at 11:48 AM Yufei Gu <[email protected]> wrote: > Hi folks, > > I've been working on a change [1] and would like to get feedback. The > change introduces two related capabilities: > > 1. > > Tables and views created without an explicit location will use unique > table locations by default. Please note that this is a behavior change. > 2. > > Operators can optionally disable client-specified locations in create > table/view requests via a feature flag > ALLOW_CLIENT_SPECIFIED_TABLE_LOCATION. The flag is disabled by default > to > preserve the current behavior. > > Existing tables and views are unaffected. Federated catalogs and register > table/view workflows are also unaffected. > > Using unique table locations by default has a few benefits: > > - It avoids accidental overlap between tables sharing the same namespace > or storage location. > - It provides stronger isolation between tables, making table lifecycle > operations such as drop, purge, and maintenance (e.g., removing orphan > files) safer. > - It makes the overlapping check logic easier and faster. We don't have > to worry about location conflicts under a structured table location (the > default setting). > > This direction also aligns with the intent of recent Iceberg discussions > [2] around unique table locations and catalog managed storage. > > Personally, I think enabling unique table locations by default is the right > choice. For organizations that want stricter control over storage > locations, disabling ALLOW_CLIENT_SPECIFIED_TABLE_LOCATION provides a > straightforward way to enforce catalog managed placement. > > I'd be interested in hearing the community's thoughts on both the overall > direction and the proposed defaults. > > 1. https://github.com/apache/polaris/pull/4606 > > 2. https://github.com/apache/iceberg/pull/12892 > > Thanks, > > Yufei >
