Hi Yufei, I agree that the situation is tricky.
Option 1 is indeed expensive, but option 2 would actually prevent someone who cleaned up their warehouse so that all tables comply, from genuinely switching to structured mode. Conceptually, this feels wrong to me, because we are preventing a transition from a less secure setup to a more secure setup. Another concern I have is a practical one: if the flag is set at the realm level, how is Polaris going to detect the change? Instead, how about a mix of documentation + a dedicated tool that could report all the tables that *would* fail if structured mode is switched on? Thanks, Alex On Wed, Oct 28, 2026 at 1:19 AM Yufei Gu <[email protected]> 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?
