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? >
