Hi Dmitri, +1 on using only StorageAccessConfig for server-side FileIO.
I'll take the cleanup PR once this settles. Test/dev paths that today put MinIO endpoint and keys on table-default.s3.* when AccessConfig is empty will need those on storage config instead. We can cover that in the PR. WDYT?? Thanks, *Vignesh* [5328] https://github.com/apache/polaris/pull/5328 On Wed, 7 Oct 2026 at 00:21, Dmitri Bourlatchkov <[email protected]> wrote: > Cross-referencing related discussion: > > https://lists.apache.org/thread/49vsx3r803nmf35wsyxl2h3qvxfrrfgs > > On Tue, Oct 6, 2026 at 2:46 PM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi All, > > > > This discussion stems [1] from PR [5328], but it is rooted in more > > fundamental Polaris behaviours. > > > > ATM the codebase uses a combination of StorageAccessConfig and _default_ > > table properties for constructing server-side FileIO objects. > > > > Note that it already deviates from what clients may use. > > > > Load table responses advertise FileIO-related properties in the REST > > API-level config section. These properties include vended credentials and > > endpoints. > > > > Generally, IRC config properties are sufficient for clients to construct > > operational FileIO objects to access storage files for tables loaded via > > Polaris. > > > > Therefore, I propose that Polaris code use only StorageAccessConfig for > > constructing server-side FileIO objects. > > > > Thoughts? > > > > [1] https://github.com/apache/polaris/pull/5328#discussion_r4184400135 > > > > [5328] https://github.com/apache/polaris/pull/5328 > > > > Cheers, > > Dmitri. > > > > >
