Hi guys, I agree with Alex and Russell: we should not block true -> false.
Let's start with prep step before the 1.9.0 release as you proposed: 1. We document the caveat in the configuration docs and upgrade notes. 2. The report command to the admin tool makes sense. A read-only command that walks the catalog (or realm) and lists the tables/views whose locations would fail the structured check. That can come in a follow-up after 1.9.0 release. Regards JB On Wed, Oct 28, 2026 at 5:40 PM Yufei Gu <[email protected]> wrote: > > 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? > > > > >
