eric-maynard opened a new pull request, #1557: URL: https://github.com/apache/polaris/pull/1557
Previously, some `FeatureConfiguration`s could have a `catalogConfig` which allowed admins to enable or disable the feature on a per-catalog basis. Unfortunately, config itself was a freeform string. This means that new configs could potentially collide with existing configs. For example, imagine a user has had a catalog with some property `delete.everything.yes` since they started using Polaris with release 0.9.0. At some point in time, we add a new `FeatureConfiguration` with `catalogConfig` `delete.everything.yes`. When the user upgrades their Polaris, whatever new behavior is gated behind that catalog config will be silently enabled. To prevent this, catalog configs should start with the reserved `polaris.` prefix, so that they cannot collide with existing properties. We can whitelist the configs on an individual basis so that once a catalog config is defined its property can be used, but not before that time. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@polaris.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
