I got that a flawed feature isn't a bug :-). My main concern is that it breaks other important features, like credential vending and table updates, which occur much more frequently than updating the flag. Are we OK with this? Maybe it's fine given that only the catalog admin has the permission. Let's document this caveat first. Having a tool to check all locations under a catalog is also a good idea.
Yufei On Wed, Oct 28, 2026 at 8:23 AM Russell Spitzer <[email protected]> wrote: > I beat you to it Alex :) I see we are thinking alike. > > On Wed, Oct 28, 2026 at 10:21 AM Alex Dutra <[email protected]> wrote: > > > 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? > > >
