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
