cobed95 opened a new issue, #4944: URL: https://github.com/apache/polaris/issues/4944
### Is your feature request related to a problem? Please describe. When using the `relational-jdbc` persistence backend with PostgreSQL, Polaris always creates and uses a schema named `POLARIS_SCHEMA`. The name is hardcoded and cannot be changed through configuration: - Table references are built as `"POLARIS_SCHEMA." + tableName` in `QueryGenerator.getFullyQualifiedTableName(...)` (`persistence/relational-jdbc/.../jdbc/QueryGenerator.java`), directly under a `// TODO: make schema name configurable.` comment. - The version lookup hardcodes `SELECT version_value FROM POLARIS_SCHEMA.VERSION`. - The bootstrap scripts (`persistence/relational-jdbc/src/main/resources/postgres/schema-v*.sql`, plus the `h2` and `cockroachdb` equivalents) contain `CREATE SCHEMA IF NOT EXISTS POLARIS_SCHEMA;` and `SET search_path TO POLARIS_SCHEMA;`. The only JDBC options exposed today (`RelationalJdbcConfiguration`) are `maxRetries`, `maxDurationInMs`, `initialDelayInMs`, and `databaseType` — there is no way to set the schema. This is a problem when: - An organization's database governance requires a specific schema name / naming convention, or restricts who may create new schemas. - Multiple Polaris deployments or environments must coexist within a single database and need separate schemas to stay isolated. - Users have an existing schema/naming standard they must conform to. Related earlier discussion for the (now legacy) EclipseLink backend: #1116. That request was about avoiding the `public` schema; the JDBC backend addressed it by hardcoding `POLARIS_SCHEMA`, but the value still isn't configurable. ### Describe the solution you'd like A configuration option — for example `polaris.persistence.relational.jdbc.schema-name` — that sets the schema used for all Polaris tables, defaulting to `POLARIS_SCHEMA` so existing deployments are unaffected. The configured value would be applied both when generating queries and when running the bootstrap scripts. Because the schema name is interpolated into SQL rather than passed as a bind parameter, it would need to be validated as a plain SQL identifier. Since this touches `RelationalJdbcConfiguration` (an extension point) and the query-generation path, I'm happy to bring a concrete design to the dev mailing list first before opening a PR. ### Describe alternatives you've considered - Using a separate database per deployment instead of a separate schema — this achieves isolation but does not satisfy schema-naming requirements and complicates consolidating deployments into one database. - Renaming the schema out of band after bootstrap — brittle and unsupported, and would break the hardcoded query references. ### Additional context - Affected module: `persistence/relational-jdbc`. - Key references: `QueryGenerator.java` (`getFullyQualifiedTableName`, `generateVersionQuery`), `RelationalJdbcConfiguration.java`, `DatasourceOperations.executeScript(...)`, and the `postgres` / `h2` / `cockroachdb` `schema-v*.sql` resources. - The existing `// TODO: make schema name configurable.` in `QueryGenerator` indicates this was already anticipated. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
