Hi Vignesh, +1 on defining this and keeping polaris.config.* out of the Iceberg /v1/config response. I agree these are server/operator settings rather than Iceberg client configuration.
They're consumed server-side through realmConfig.getConfig(...), and I can't think of a polaris.config.* key that an Iceberg client reads from the defaults today. One concrete example from the soft-delete work in PR [5544]: it adds polaris.config.table-soft-delete.enabled, .hold-period and .purge-data-on-permanent-delete as catalog overrides. These are purely server-side settings and clients never read them. Once that PR lands, they'd start showing up in /v1/config under the current "whole properties bag" behaviour, even though no client consumes them. Seems like a good reason to exclude them. One small suggestion on the implementation: instead of enumerating the current polaris.config.* keys to exclude, could we strip everything with the polaris.config. prefix? That way, new catalog overrides like the soft-delete ones are excluded by default, rather than silently making their way into the response until someone adds them to a denylist. The other keys (default-base-location, operator custom keys, and Iceberg catalog properties) would still be included in the defaults as you described. WDYT? Thanks, Prithvi [5544] https://github.com/apache/polaris/pull/5544
