Hi Yufei I agree that a config change that works and then surfaces as a 403 later is the worst :)
I have a preference on option 2 with some comments: 1. As you noted, the check should apply to the effective value. That covers explicitly setting false and removing the property when the default or inherited value is false. It should also cover any other path that changes the effective value, such as a realm-level default change. 2. Catalogs that already have the flag set to false should not be affected. We only reject the transition, so they keep working. Creating a catalog with the flag false should stay allowed, since there are no existing locations to invalidate. 3. The rejection should be a clear 4xx with a message explaining why, so users don't read it as a bug. Since this is a behavior change for anyone using the flag today, I think it deserves a CHANGELOG and clear state in the documentation. 4. Maybe we could consider option 1 as a follow-up. Regards JB On 2026-10-28 00:19 UTC Yufei Gu wrote: > Hi all, > > While reviewing #5856 (https://github.com/apache/polaris/pull/5856), I > noticed that we allow changing ALLOW_UNSTRUCTURED_TABLE_LOCATION from true > to false without checking existing table/view locations. This can break > tables that were valid under the previous setting. > > For example: > > - Create ns1.t1 at its default location with the flag enabled. > - Rename it to ns2.t2. The data stays under ns1. > - Turn the flag off. Loading the table with credentials can now fail > with a 403 because its location is outside ns2. > > The catalog update succeeds, but the problem shows up when someone accesses > the table later. > > I see two options: > > 1. Verify every table/view before allowing the change, and reject it if > any location is incompatible. This could be very expensive for large > catalogs. We can consider it as phase 2. > 2. Block true → false altogether for now. This should also cover > removing the property when that makes the effective value false. We can > still allow false → true. > > I’d lean toward option 2 for now. It seems better to reject the > configuration change than let it succeed and break existing tables > afterward. > > Any concerns with this approach? >
