Hi all, I'd like to get feedback on a small enhancement to the Relational JDBC persistence backend before moving the PR out of draft.
Problem The backend currently hard-codes its database schema as POLARIS_SCHEMA -- both in QueryGenerator (there's an existing "// TODO: make schema name configurable.") and in the bootstrap SQL scripts. This makes it impossible to comply with a schema-naming policy that organizations might have. It came up while looking at issue #1116 (the older EclipseLink "avoid public schema" request); the JDBC backend fixed the "not public" part by hard-coding a name, but the value still isn't configurable. Issue: https://github.com/apache/polaris/issues/4944 Draft PR: https://github.com/apache/polaris/pull/4945 Proposed change Add polaris.persistence.relational.jdbc.schema-name, defaulting to POLARIS_SCHEMA so existing deployments are unaffected. The value is validated as a plain SQL identifier (it's interpolated into SQL, not bound). Bootstrap scripts use a ${schema} placeholder substituted at script-execution time so the configured schema is created and used consistently. Points I'd like input on 1. This adds a method to RelationalJdbcConfiguration, which is an extension point -- hence this discussion per CONTRIBUTING.md. 2. To wire the schema through, I converted QueryGenerator from a static utility to an instance bound to the schema. That's the bulk of the diff (mechanical call-site updates). An alternative is threading the schema through method parameters; the instance approach seemed cleaner, but I'm happy to change direction. 3. For the admin tool, I exposed the schema as the same config property rather than a separate CLI flag, so the admin tool and server can't bootstrap into different schemas. Let me know if a CLI flag is preferred despite that drift risk. Feedback welcome -- I'll hold the PR in draft until there's consensus. Thanks, Eundo Lee
