Hi all, This is just a friendly reminder for PR #4945 (Make the Relational JDBC schema name configurable). I understand that the maintainers are quite busy with preparation of the 1.8.0 release. I would love to see this PR make it into 1.9.0 so that my org can deploy and use Polaris in production.
Thank you. With regards, Eundo 2026년 8월 21일 (금) 오후 12:40, Eundo Lee <[email protected]>님이 작성: > Hi all, > > I would like to express my sincere gratitude to Alex, Yufei and Robert > for the in-depth discussion. I'll update the PR to reflect Robert's > additional review on comments and rebase it on top of main. > > Personally, although my original approach was to bring in a new > Polaris configuration, I eventually leaned towards Alex's point of view. > This was because I believed that operators should know and be > responsible for JDBC driver configurations. > > While Polaris can provide guidance on how to configure databases > for optimal performance, I believe such configuration should not be > coded into the source code. This may come as a surprising black box > for operators. > > However, if the community leans towards a new Polaris configuration, > I'm happy to modify my approach. > > Thanks, > > Eundo Lee > > > 2026년 8월 21일 (금) 오전 12:25, Robert Stupp <[email protected]>님이 작성: > >> Thanks, Alex. >> >> I support making the schema/namespace configurable, and I support moving >> forward with the current PR once it is rebased on main and the current >> checks >> pass. >> >> The current change gives the supported databases a concrete, driver-native >> configuration contract. >> >> A Polaris-owned property remains a plausible alternative, but it would >> need >> its own defined per-driver mappings, validation, upgrade behavior, and >> ownership model. >> >> The remaining question is whether there is a concrete correctness or >> compatibility concern with the current driver-native path that requires a >> change before merge. >> >> At present, I have not seen a concrete correctness or compatibility >> requirement that the current driver-native path fails to meet. >> >> If not, I support merging this PR and treating the Polaris-owned >> abstraction >> as a clearly scoped follow-up. >> >> >> On Thu, Aug 20, 2026 at 4:48 PM Alexandre Dutra <[email protected]> >> wrote: >> >> > Hi Yufei, >> > >> > Your point that Polaris already branches on DatabaseType is fair, but >> > that branching is a cost we try to minimize, not a pattern we should >> > build on. >> > >> > As for the Connector/J documentation you linked, I think it is being >> > read slightly out of context: the "Always use Connection.setCatalog() >> > rather than the USE database statement" note is a narrow best practice >> > for JDBC code that needs to switch databases dynamically at runtime; >> > it is not recommending setCatalog() as the standard way to configure >> > the initial database connection. The same paragraph makes the primary >> > recommendation clear: specify the database in the JDBC URL. >> > setCatalog() is a fallback for when the URL has no database. >> > >> > More broadly, why should Polaris call JDBC APIs at all when standard >> > configuration is sufficient? Having Polaris invoke setCatalog() (or >> > setSchema()) at connection-initialization time means adding custom >> > connection-lifecycle code in Polaris for something operators can >> > already express as plain configuration. That is complexity we would >> > own and maintain indefinitely. >> > >> > Anyways, I am not sure we are going to agree on this topic, so it's >> > probably best to just disagree and commit. The PR is already approved. >> > If no strong objections are raised, I suggest that we merge it in the >> > coming days. Would that work for you and for others as well? >> > >> > Thanks, >> > Alex >> > >> > On Wed, Aug 19, 2026 at 11:09 PM Yufei Gu <[email protected]> wrote: >> > > >> > > Hi Alex, I agree that MySQL does not have PostgreSQL-style schemas >> nested >> > > below a database; in MySQL, SCHEMA is a synonym for DATABASE[1], users >> > can >> > > do either CREATE DATABASE db_name or CREATE SCHEMA db_name. >> > > >> > > However, I do not think that leaves only the two options of ignoring >> the >> > > property or rewriting the JDBC URL. Connector/J represents the current >> > > MySQL database as a JDBC catalog and explicitly recommends using >> > > Connection.setCatalog() to select it[2]. Connector/J can also expose >> > > databases through the JDBC schema APIs when databaseTerm=SCHEMA is >> > > configured. If and when MySQL is supported, a Polaris-owned property >> > could >> > > therefore refer to the database namespace containing the Polaris >> tables: >> > > >> > > - PostgreSQL/CockroachDB: a schema >> > > - H2: a schema >> > > - MySQL: a database/catalog >> > > >> > > The difference would need to be documented, particularly that MySQL >> > cannot >> > > place multiple such namespaces inside one database, but the property >> > would >> > > neither be ignored nor require JDBC URL manipulation. I agree that >> this >> > > entails some database-specific interpretation. My argument is not that >> > the >> > > mapping is free, but that currentSchema is itself driver-specific and >> > moves >> > > that interpretation to operators. A Polaris-owned property would keep >> the >> > > operator-facing default, validation, and upgrade behavior under >> Polaris’s >> > > control. Polaris already has database-specific handling through >> > > DatabaseType and separate bootstrap resources, so this mapping would >> fit >> > > the existing structure. >> > > >> > > References: >> > > [1] https://dev.mysql.com/doc/refman/8.4/en/create-database.html >> > > [2] >> > > >> > >> https://dev.mysql.com/doc/connector-j/en/connector-j-reference-jdbc-url-format.html >> > > [3] >> > > >> > >> https://dev.mysql.com/doc/connectors/en/connector-j-connp-props-connection.html >> > > >> > > Yufei >> > > >> > > >> > > On Wed, Aug 19, 2026 at 3:38 AM Alexandre Dutra <[email protected]> >> > wrote: >> > > >> > > > Hi Yufei, >> > > > >> > > > I want to challenge the "driver-agnostic abstraction" premise again, >> > > > because I believe it is the opposite of what a Polaris-specific >> > > > property would deliver. >> > > > >> > > > For polaris.persistence.relational.jdbc.schema-name to work across >> > > > drivers, Polaris would need to translate it into the appropriate >> > > > driver-level mechanism for each supported database. >> > > > >> > > > MySQL is the clearest illustration of why that translation is not >> > > > straightforward: MySQL has no concept of a schema below a database, >> > > > and therefore there is no "current schema" connection property to >> set. >> > > > So either Polaris ignores the property on MySQL (making the >> > > > abstraction dishonest) or it tries to inject the value into the JDBC >> > > > URL (fragile). Neither outcome is better than what we have now in >> > > > Eundo's PR. >> > > > >> > > > Far from hiding driver-specific concerns, a Polaris-owned property >> > > > would require us to accumulate per-driver translation logic inside >> > > > Polaris, which is exactly what you are trying to avoid, just at a >> > > > higher layer. >> > > > >> > > > Thanks, >> > > > Alex >> > > > >> > > > >> > > > On Wed, Aug 19, 2026 at 3:03 AM Yufei Gu <[email protected]> >> wrote: >> > > > > >> > > > > I agree that PostgreSQL is unlikely to change this behavior >> > unexpectedly. >> > > > > Still, I think Eundo’s original approach is more robust. >> Introducing >> > a >> > > > > Polaris-specific property such as >> > > > > polaris.persistence.relational.jdbc.schema-name, instead of >> relying >> > > > > directly on quarkus.datasource.jdbc.additional-jdbc-properties.*, >> > would >> > > > > provide a stable, driver-agnostic abstraction. This would support >> > > > different >> > > > > JDBC drivers consistently(e.g., the quakus config doesn't work for >> > mysql >> > > > > driver) and insulate Polaris from driver-specific configuration >> > details >> > > > or >> > > > > future behavioral changes. >> > > > > >> > > > > This is less about anticipating a breaking PostgreSQL change and >> more >> > > > about >> > > > > keeping driver-specific concerns behind a Polaris-owned >> configuration >> > > > > interface. >> > > > > Yufei >> > > > > >> > > > > >> > > > > On Tue, Aug 18, 2026 at 8:00 AM Alexandre Dutra < >> [email protected]> >> > > > wrote: >> > > > > >> > > > > > Hi Yufei, >> > > > > > >> > > > > > > My main concern is still that currentSchema, after >> > > > > > quarkus.datasource.jdbc.additional-jdbc-properties, is part of a >> > > > freeform >> > > > > > key-value configuration and just happens to be honored by the >> > current >> > > > > > PostgreSQL driver. We should avoid depending on driver-specific >> > > > behavior if >> > > > > > possible. >> > > > > > >> > > > > > I believe you are overstating this risk. >> > > > > > >> > > > > > JDBC driver configuration does not adhere to any standard, >> > resulting >> > > > > > in dramatically different syntax for pathing, parameter >> delimiters, >> > > > > > and authentication placement across database vendors. This is >> valid >> > > > > > for both JDBC connection strings, and JDBC properties. >> > > > > > >> > > > > > However, that does not mean JDBC configuration is completely >> > > > > > unpredictable. Each vendor explicitly defines, documents, and >> > > > > > maintains its driver's supported JDBC properties as part of a >> > formal >> > > > > > configuration surface. Drivers rarely, if ever, modify these >> > > > > > parameters in a breaking manner. >> > > > > > >> > > > > > As a result, describing additional-jdbc-properties as a >> "freeform >> > > > > > key-value configuration" is misleading, and the concern that the >> > > > > > PostgreSQL driver might suddenly alter this behavior is largely >> > moot: >> > > > > > such a change is highly unlikely. >> > > > > > >> > > > > > Therefore, Eundo's PR remains the most practical path forward. >> > While >> > > > > > we could technically embed the schema name in the connection URL >> > via >> > > > > > quarkus.datasource.jdbc.url, doing so would disrupt existing >> > > > > > environments because that property is widely customized. Using >> > > > > > additional-jdbc-properties provides a cleaner, >> backwards-compatible >> > > > > > path for upgrades. >> > > > > > >> > > > > > Thanks, >> > > > > > Alex >> > > > > > >> > > > > > On Thu, Aug 13, 2026 at 12:16 AM Yufei Gu <[email protected] >> > >> > > > wrote: >> > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > >> > >> quarkus.datasource.jdbc.additional-jdbc-properties.currentSchema=POLARIS_SCHEMA >> > > > > > > >> > > > > > > My main concern is still that currentSchema, after >> > > > > > > quarkus.datasource.jdbc.additional-jdbc-properties, is part >> of a >> > > > freeform >> > > > > > > key-value configuration and just happens to be honored by the >> > current >> > > > > > > PostgreSQL driver. We should avoid depending on >> driver-specific >> > > > behavior >> > > > > > if >> > > > > > > possible. We may need to support additional drivers in the >> > future, >> > > > and >> > > > > > the >> > > > > > > PostgreSQL driver's behavior could also change. Don't get me >> > wrong. >> > > > I'm >> > > > > > not >> > > > > > > saying these future use cases cannot be addressed, but I >> think we >> > > > should >> > > > > > > avoid introducing them if possible. Given that adding a >> > > > Polaris-specific >> > > > > > > configuration is relatively easy, I'd suggest going that >> route. >> > > > > > > >> > > > > > > The upgrade concern is a relatively minor point. Even if we >> ship >> > the >> > > > > > > default config, existing users would still need to manually >> pick >> > up >> > > > the >> > > > > > new >> > > > > > > defaults and merge them into their existing configuration. >> > > > > > > >> > > > > > > Yufei >> > > > > > > >> > > > > > > >> > > > > > > On Tue, Aug 11, 2026 at 7:29 AM Eundo Lee <[email protected]> >> > wrote: >> > > > > > > >> > > > > > > > Hi all, >> > > > > > > > >> > > > > > > > I would like to call for more reviewers' attention to this >> > > > discussion >> > > > > > and >> > > > > > > > PR with >> > > > > > > > all respect. >> > > > > > > > >> > > > > > > > I personally strongly believe that this PR is in the >> direction >> > of >> > > > > > > > introducing Polaris >> > > > > > > > to a wider audience. Schema inconfigurability, in my >> opinion, >> > can >> > > > in >> > > > > > fact >> > > > > > > > be the >> > > > > > > > single blocker for new users to adopt Polaris. >> > > > > > > > >> > > > > > > > With that said, I would love to see more reviewers engaging >> > with >> > > > this >> > > > > > > > topic. >> > > > > > > > >> > > > > > > > With regards, >> > > > > > > > Eundo. >> > > > > > > > >> > > > > > > > >> > > > > > > > 2026년 8월 8일 (토) 오후 4:45, Eundo Lee <[email protected]>님이 >> 작성: >> > > > > > > > >> > > > > > > > > Hi Yufei, >> > > > > > > > > >> > > > > > > > > Sorry for the late reply. >> > > > > > > > > >> > > > > > > > > Thanks, that's a fair thing to be careful about -- an >> upgrade >> > > > that >> > > > > > > > silently >> > > > > > > > > starts reading from the wrong schema would be exactly the >> > kind of >> > > > > > failure >> > > > > > > > > an >> > > > > > > > > operator wouldn't catch until it's already caused damage. >> > Let me >> > > > lay >> > > > > > out >> > > > > > > > > why I >> > > > > > > > > believe existing deployments are safe without any operator >> > > > action. >> > > > > > > > > >> > > > > > > > > The shipped defaults in runtime/defaults and the admin >> tool >> > set >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > >> > > > >> > >> quarkus.datasource.jdbc.additional-jdbc-properties.currentSchema=POLARIS_SCHEMA, >> > > > > > > > > which is exactly the schema name the code hard-coded >> before. >> > So >> > > > an >> > > > > > > > > operator who >> > > > > > > > > upgrades and changes nothing gets the same schema >> selection >> > they >> > > > had >> > > > > > on >> > > > > > > > > the old >> > > > > > > > > release, pointed at the schema their prior Polaris already >> > > > created. >> > > > > > > > > There's no >> > > > > > > > > "you must edit your datasource config or you break" step >> on >> > the >> > > > > > upgrade >> > > > > > > > > path -- >> > > > > > > > > the behavior is preserved precisely so that the common >> case >> > > > requires >> > > > > > no >> > > > > > > > > action. >> > > > > > > > > >> > > > > > > > > On the "administrators won't touch datasource config >> during >> > an >> > > > > > upgrade" >> > > > > > > > > point: I >> > > > > > > > > agree they generally won't, and the design leans on that >> > rather >> > > > than >> > > > > > > > > against it. >> > > > > > > > > The datasource configuration (URL, credentials, and the >> > database >> > > > > > itself) >> > > > > > > > > is the >> > > > > > > > > one piece an operator already has to own for JDBC >> > persistence to >> > > > > > work at >> > > > > > > > > all, so >> > > > > > > > > we're not introducing a new configuration surface they >> have >> > to >> > > > learn >> > > > > > -- >> > > > > > > > > we're >> > > > > > > > > shipping a default value in the same block they already >> > provide. >> > > > > > > > > >> > > > > > > > > The one genuine behavior change is that Polaris no longer >> > issues >> > > > > > CREATE >> > > > > > > > > SCHEMA, >> > > > > > > > > so a *fresh* deployment now needs the schema created >> before >> > > > > > bootstrap. >> > > > > > > > That >> > > > > > > > > doesn't affect existing deployments, whose schema already >> > exists >> > > > > > from the >> > > > > > > > > prior >> > > > > > > > > version; it only affects new installs, and it's called out >> > as a >> > > > > > breaking >> > > > > > > > > change >> > > > > > > > > in the docs with the two-step procedure. If it would help, >> > I'm >> > > > happy >> > > > > > to >> > > > > > > > > make >> > > > > > > > > that more prominent in the release notes so a >> fresh-install >> > > > operator >> > > > > > > > can't >> > > > > > > > > miss >> > > > > > > > > it. >> > > > > > > > > >> > > > > > > > > So concretely: upgrade with no config change -> works, >> same >> > > > schema as >> > > > > > > > > before; >> > > > > > > > > fresh install -> create the schema first, as documented. I >> > don't >> > > > see >> > > > > > a >> > > > > > > > path >> > > > > > > > > where an existing operator has to change their setup to >> keep >> > > > > > working, but >> > > > > > > > > if you >> > > > > > > > > can think of one I've missed I'd genuinely like to close >> it >> > > > before >> > > > > > this >> > > > > > > > > lands. >> > > > > > > > > >> > > > > > > > > Thanks, >> > > > > > > > > Eundo >> > > > > > > > > >> > > > > > > > > 2026년 8월 4일 (화) 오전 7:28, Yufei Gu <[email protected] >> >님이 >> > 작성: >> > > > > > > > > >> > > > > > > > >> Other than coupling the data source schema name to the >> > driver's >> > > > > > > > behavior, >> > > > > > > > >> I'm also concerned that this could easily break >> downstream >> > > > systems >> > > > > > if >> > > > > > > > >> administrators miss the datasource configuration changes >> in >> > the >> > > > new >> > > > > > > > >> Polaris >> > > > > > > > >> release. I don't think most administrators would update >> > their >> > > > > > datasource >> > > > > > > > >> configuration as part of an upgrade, but I could be >> wrong. >> > > > > > > > >> >> > > > > > > > >> Yufei >> > > > > > > > >> >> > > > > > > > >> >> > > > > > > > >> On Mon, Aug 3, 2026 at 5:38 AM Alexandre Dutra < >> > > > [email protected]> >> > > > > > > > wrote: >> > > > > > > > >> >> > > > > > > > >> > Hi all, >> > > > > > > > >> > >> > > > > > > > >> > I think it's fine to just document that currentSchema >> is >> > > > specific >> > > > > > to >> > > > > > > > >> > PostgreSQL. Drivers are very diverse in terms of design >> > and >> > > > > > > > >> > configuration surface; I think it's also fine to let >> the >> > onus >> > > > > > fall on >> > > > > > > > >> > operators to properly configure the connection >> according >> > to >> > > > their >> > > > > > > > >> > driver's capabilities and configuration facade. >> > > > > > > > >> > >> > > > > > > > >> > Thanks, >> > > > > > > > >> > Alex >> > > > > > > > >> > >> > > > > > > > >> > On Wed, Jul 22, 2026 at 5:43 AM Eundo Lee < >> > [email protected]> >> > > > > > wrote: >> > > > > > > > >> > > >> > > > > > > > >> > > Hi Yufei, >> > > > > > > > >> > > >> > > > > > > > >> > > Thanks for raising this — it's a fair point, and I >> agree >> > > > it's >> > > > > > worth >> > > > > > > > >> the >> > > > > > > > >> > > community weighing in. >> > > > > > > > >> > > >> > > > > > > > >> > > I looked into how MySQL handles this and tested it >> > against a >> > > > > > real >> > > > > > > > >> MySQL >> > > > > > > > >> > > instance (Connector/J 9.1.0). A couple of findings >> > that, I >> > > > > > think, >> > > > > > > > let >> > > > > > > > >> the >> > > > > > > > >> > > driver-configuration approach hold up even with MySQL >> > in the >> > > > > > > > picture: >> > > > > > > > >> > > >> > > > > > > > >> > > - MySQL has no notion of a schema below a database — >> > > > "schema" >> > > > > > and >> > > > > > > > >> > > "database" are synonyms there. The namespace is >> > selected >> > > > by >> > > > > > the >> > > > > > > > >> > database >> > > > > > > > >> > > in the JDBC URL, which is exactly what the MySQL PR >> > > > (#4281) >> > > > > > > > already >> > > > > > > > >> > does: >> > > > > > > > >> > > jdbc:mysql://<host>:3306/POLARIS_SCHEMA. So MySQL's >> > > > namespace >> > > > > > is >> > > > > > > > >> also >> > > > > > > > >> > > selected through standard datasource configuration; >> > it's >> > > > just >> > > > > > a >> > > > > > > > >> > different >> > > > > > > > >> > > property, because that is how MySQL natively models >> > it. In >> > > > > > both >> > > > > > > > >> cases >> > > > > > > > >> > the >> > > > > > > > >> > > persistence layer stays agnostic of the schema >> name. >> > > > > > > > >> > > >> > > > > > > > >> > > - The shipped currentSchema default is harmless on >> > MySQL. >> > > > It is >> > > > > > set >> > > > > > > > on >> > > > > > > > >> > the >> > > > > > > > >> > > default (PostgreSQL) datasource, and #4281 exposes >> > MySQL >> > > > as a >> > > > > > > > >> separate >> > > > > > > > >> > > named datasource, so it does not apply there. And >> > even if >> > > > it >> > > > > > were >> > > > > > > > >> > applied, >> > > > > > > > >> > > MySQL Connector/J silently ignores currentSchema — >> I >> > > > verified >> > > > > > that >> > > > > > > > >> it >> > > > > > > > >> > > connects without error and the property simply has >> no >> > > > effect. >> > > > > > (A >> > > > > > > > >> > database >> > > > > > > > >> > > in the URL also overrides currentSchema on both >> > > > PostgreSQL and >> > > > > > > > >> MySQL.) >> > > > > > > > >> > > >> > > > > > > > >> > > So a Polaris-owned generic schema-name would not >> > actually >> > > > buy >> > > > > > MySQL >> > > > > > > > >> > > anything: there is nothing below the database for it >> to >> > > > > > translate >> > > > > > > > to, >> > > > > > > > >> so >> > > > > > > > >> > it >> > > > > > > > >> > > would either no-op or duplicate the URL database — >> while >> > > > > > > > reintroducing >> > > > > > > > >> > the >> > > > > > > > >> > > extension-point change and the per-driver >> quoting/casing >> > > > logic >> > > > > > that >> > > > > > > > >> this >> > > > > > > > >> > > rework removed. >> > > > > > > > >> > > >> > > > > > > > >> > > That said, the generic approach does offer one real >> > thing: a >> > > > > > single >> > > > > > > > >> > uniform >> > > > > > > > >> > > knob, so operators don't have to know each driver's >> > idiom. >> > > > My >> > > > > > > > >> preference >> > > > > > > > >> > is >> > > > > > > > >> > > the driver-configuration approach, but I'm genuinely >> > fine >> > > > either >> > > > > > > > way, >> > > > > > > > >> > and if >> > > > > > > > >> > > the community leans toward the uniform knob it's a >> > bounded >> > > > > > change to >> > > > > > > > >> > layer >> > > > > > > > >> > > back on. >> > > > > > > > >> > > >> > > > > > > > >> > > To avoid surprises in the meantime, I've documented >> in >> > the >> > > > Helm >> > > > > > > > values >> > > > > > > > >> > that >> > > > > > > > >> > > currentSchema is PostgreSQL/CockroachDB-specific and >> is >> > > > silently >> > > > > > > > >> ignored >> > > > > > > > >> > by >> > > > > > > > >> > > MySQL (where the schema is the database in the URL). >> > > > > > > > >> > > >> > > > > > > > >> > > Thanks again for the careful review! >> > > > > > > > >> > > >> > > > > > > > >> > > Eundo >> > > > > > > > >> > > >> > > > > > > > >> > > 2026년 7월 22일 (수) 오전 10:10, Yufei Gu < >> > [email protected] >> > > > >님이 >> > > > > > 작성: >> > > > > > > > >> > > >> > > > > > > > >> > > > Thanks a lot for working on this, Eundo. The new >> > > > approach[1] >> > > > > > > > >> > introduces a >> > > > > > > > >> > > > hard dependency on the driver's behavior. It's fine >> > now >> > > > since >> > > > > > the >> > > > > > > > >> > > > PostgreSQL driver is the only JDBC driver needed in >> > > > > > production. >> > > > > > > > >> > However, >> > > > > > > > >> > > > there is an effort to support MySQL. In that case, >> we >> > may >> > > > > > need a >> > > > > > > > >> > different >> > > > > > > > >> > > > way to inject the schema name. >> > > > > > > > >> > > > The previous approach is a more generic in that >> > regard, >> > > > > > though it >> > > > > > > > >> > involves >> > > > > > > > >> > > > a bit more complexity. Personally, I'm fine with >> > either >> > > > > > approach, >> > > > > > > > >> but >> > > > > > > > >> > I'd >> > > > > > > > >> > > > like to hear more opinions from the community. >> > > > > > > > >> > > > >> > > > > > > > >> > > > 1. >> > > > > > > > >> > https://github.com/apache/polaris/pull/4945/changes#r3626702105 >> > > > > > > > >> > > > >> > > > > > > > >> > > > Yufei >> > > > > > > > >> > > > >> > > > > > > > >> > > > >> > > > > > > > >> > > > On Tue, Jul 21, 2026 at 12:40 AM Eundo Lee < >> > > > [email protected] >> > > > > > > >> > > > > > > > >> wrote: >> > > > > > > > >> > > > >> > > > > > > > >> > > > > Hi all, >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > A quick update: the rework discussed on this >> thread >> > has >> > > > > > landed >> > > > > > > > on >> > > > > > > > >> > the PR, >> > > > > > > > >> > > > > and it now follows the direction Alex proposed — >> the >> > > > > > Relational >> > > > > > > > >> JDBC >> > > > > > > > >> > > > > persistence layer is completely agnostic of the >> > schema >> > > > name. >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > What changed: >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > - The schema is selected entirely through the >> JDBC >> > > > driver's >> > > > > > > > >> > currentSchema >> > > > > > > > >> > > > > connection property; the persistence code no >> > longer >> > > > > > qualifies >> > > > > > > > >> SQL, >> > > > > > > > >> > > > > validates a schema name, or sets a session >> schema. >> > > > There >> > > > > > is no >> > > > > > > > >> > > > > Polaris-level configuration option and no >> > > > extension-point >> > > > > > > > >> change -- >> > > > > > > > >> > > > > RelationalJdbcConfiguration is unchanged from >> > main. >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > - A default is shipped in runtime/defaults and >> the >> > admin >> > > > > > tool >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > >> > > > > > > > >> > > > >> > > > > > > > >> > >> > > > > > > > >> >> > > > > > > > >> > > > > > >> > > > >> > >> (quarkus.datasource.jdbc.additional-jdbc-properties.currentSchema=POLARIS_SCHEMA), >> > > > > > > > >> > > > > so upgrades and the out-of-the-box experience >> are >> > > > > > unchanged. A >> > > > > > > > >> > > > > currentSchema set in the JDBC URL takes >> precedence >> > > > over it >> > > > > > > > >> > (verified >> > > > > > > > >> > > > > against PostgreSQL and CockroachDB). >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > - Polaris no longer issues CREATE SCHEMA: the >> > schema is >> > > > a >> > > > > > > > >> > prerequisite >> > > > > > > > >> > > > > created by a DBA. Fresh deployments are a >> two-step >> > > > > > procedure >> > > > > > > > >> > (create >> > > > > > > > >> > > > the >> > > > > > > > >> > > > > schema, then bootstrap); this is a documented >> > breaking >> > > > > > change. >> > > > > > > > >> The >> > > > > > > > >> > > > > getting-started compose assets and the Helm >> test >> > > > fixture >> > > > > > > > create >> > > > > > > > >> the >> > > > > > > > >> > > > > schema at the database-provisioning layer, so >> the >> > > > > > tutorials >> > > > > > > > >> > themselves >> > > > > > > > >> > > > > are unchanged. >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > - The Helm chart exposes >> > > > > > > > >> > persistence.relationalJdbc.additionalProperties >> > > > > > > > >> > > > > (default {currentSchema: POLARIS_SCHEMA}), >> which >> > also >> > > > > > leaves >> > > > > > > > >> room >> > > > > > > > >> > for >> > > > > > > > >> > > > > other JDBC driver properties. >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > The PR is out of draft and ready for review: >> > > > > > > > >> > > > > https://github.com/apache/polaris/pull/4945 >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > Thanks to Alex for the thorough review that got >> us >> > to a >> > > > much >> > > > > > > > >> cleaner >> > > > > > > > >> > > > > solution, and to Yufei and Dmitri for the input >> on >> > the >> > > > > > > > >> > schema-version and >> > > > > > > > >> > > > > legacy-script questions. Further review and >> > feedback are >> > > > > > very >> > > > > > > > >> > welcome. >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > Thanks, >> > > > > > > > >> > > > > Eundo >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > 2026년 7월 21일 (화) 오전 11:16, Eundo Lee < >> > [email protected] >> > > > >님이 >> > > > > > 작성: >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > > Hi Alex, >> > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > Thanks for your input! >> > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > 1. I'll keep my changes on the PR that add the >> > default >> > > > > > > > >> > > > > > >> > > > > > quarkus.datasource.jdbc.additional-jdbc-properties.currentSc >> > > > > > > > >> > > > > > hema=POLARIS_SCHEMA >> > > > > > > > >> > > > > > 2. I'll brainstorm further and see if I can >> find >> > some >> > > > way! >> > > > > > > > >> > > > > > 3. Thanks for the great suggestion. I totally >> > agree >> > > > and >> > > > > > will >> > > > > > > > >> > reflect >> > > > > > > > >> > > > this >> > > > > > > > >> > > > > > in the PR. >> > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > With regards, >> > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > Eundo >> > > > > > > > >> > > > > > >> > > > > > > > >> > > > > > 2026년 7월 21일 (화) 오전 5:23, Alexandre Dutra < >> > > > > > [email protected] >> > > > > > > > >님이 >> > > > > > > > >> > 작성: >> > > > > > > > >> > > > > > >> > > > > > > > >> > > > > >> Hi Eundo, >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> Thanks for the thorough analysis! I'm glad to >> see >> > > > that >> > > > > > we're >> > > > > > > > >> > > > > >> converging to a really nice solution. >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> To your points: >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> > I'd therefore propose shipping a default in >> > > > > > > > runtime/defaults: >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> > > > > > > > >> > > > >> > > > > > > > >> > >> > > > > > > > >> >> > > > > > > > >> > > > > > >> > > > >> > >> quarkus.datasource.jdbc.additional-jdbc-properties.currentSchema=POLARIS_SCHEMA >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> +1 on this idea, I think it makes migration a >> lot >> > > > easier. >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> > I think the two-step procedure is the right >> > call >> > > > for >> > > > > > > > >> production >> > > > > > > > >> > > > [...] >> > > > > > > > >> > > > > >> but it does add a manual step to every >> > quickstart, >> > > > > > > > >> > docker-compose, and >> > > > > > > > >> > > > > Helm >> > > > > > > > >> > > > > >> example >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> Indeed. I'm personally OK with that and am >> sure >> > we >> > > > can >> > > > > > find a >> > > > > > > > >> > smart >> > > > > > > > >> > > > > >> way to update the quickstart examples >> > holistically. >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> > the Helm chart's >> > > > persistence.relationalJdbc.schemaName >> > > > > > > > value >> > > > > > > > >> > could >> > > > > > > > >> > > > > stay >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> I would rather suggest a new field: >> > > > > > > > >> > > > > >> >> persistence.relationalJdbc.additionalProperties, >> > with >> > > > > > default >> > > > > > > > >> > value: { >> > > > > > > > >> > > > > >> currentSchema: POLARIS_SCHEMA }. This way we >> also >> > > > leave >> > > > > > the >> > > > > > > > >> door >> > > > > > > > >> > open >> > > > > > > > >> > > > > >> for users that want to customize other JDBC >> > > > properties. >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> Thank you for working on this! >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> Alex >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> On Sun, Jul 19, 2026 at 1:24 PM Eundo Lee < >> > > > > > [email protected] >> > > > > > > > > >> > > > > > > > >> > wrote: >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > Hi Alex, >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > Thanks for taking this further — I agree >> with >> > the >> > > > > > > > direction. >> > > > > > > > >> > > > > >> Driver-level >> > > > > > > > >> > > > > >> > schema selection is the logical endpoint of >> the >> > > > review >> > > > > > so >> > > > > > > > far >> > > > > > > > >> > > > > >> > (statement-level -> connection-level -> >> > > > driver-level), >> > > > > > and >> > > > > > > > it >> > > > > > > > >> > > > removes >> > > > > > > > >> > > > > >> the >> > > > > > > > >> > > > > >> > hardest parts of the PR from Polaris's >> > > > responsibility >> > > > > > > > >> entirely: >> > > > > > > > >> > > > > quoting, >> > > > > > > > >> > > > > >> > identifier case folding, validation, and the >> > > > > > per-database >> > > > > > > > SET >> > > > > > > > >> > > > > statements >> > > > > > > > >> > > > > >> > all become the driver's documented >> behavior. It >> > > > also >> > > > > > helps >> > > > > > > > >> with >> > > > > > > > >> > > > MySQL >> > > > > > > > >> > > > > >> > support later (#3960), and — procedurally >> nice >> > — it >> > > > > > > > >> eliminates >> > > > > > > > >> > the >> > > > > > > > >> > > > > >> > RelationalJdbcConfiguration change >> altogether, >> > so >> > > > the >> > > > > > PR no >> > > > > > > > >> > longer >> > > > > > > > >> > > > > >> touches >> > > > > > > > >> > > > > >> > an extension point at all. Most of the >> > > > already-reviewed >> > > > > > > > work >> > > > > > > > >> > > > > >> (unqualified >> > > > > > > > >> > > > > >> > generated SQL, schema-agnostic scripts for >> the >> > > > current >> > > > > > > > schema >> > > > > > > > >> > > > version) >> > > > > > > > >> > > > > >> > carries over unchanged. >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > Two points I'd like to settle before >> reworking >> > the >> > > > PR >> > > > > > in >> > > > > > > > this >> > > > > > > > >> > > > > direction: >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > 1. Upgrade compatibility. Today every >> > > > relational-jdbc >> > > > > > > > >> > deployment has >> > > > > > > > >> > > > > its >> > > > > > > > >> > > > > >> > tables in POLARIS_SCHEMA because the code >> > and >> > > > > > scripts >> > > > > > > > >> force >> > > > > > > > >> > it. >> > > > > > > > >> > > > If >> > > > > > > > >> > > > > >> the >> > > > > > > > >> > > > > >> > persistence layer becomes fully >> > > > schema-agnostic, an >> > > > > > > > >> existing >> > > > > > > > >> > > > > >> deployment >> > > > > > > > >> > > > > >> > that upgrades without adding >> currentSchema >> > to >> > > > its >> > > > > > JDBC >> > > > > > > > >> > > > > configuration >> > > > > > > > >> > > > > >> > would resolve unqualified names against >> the >> > > > default >> > > > > > > > search >> > > > > > > > >> > path — >> > > > > > > > >> > > > > >> > "public" on PostgreSQL — and break (or >> > quietly >> > > > > > > > bootstrap a >> > > > > > > > >> > second >> > > > > > > > >> > > > > set >> > > > > > > > >> > > > > >> > of tables in public, which is what #1116 >> set >> > > > out to >> > > > > > > > >> avoid). >> > > > > > > > >> > I'd >> > > > > > > > >> > > > > >> > therefore propose shipping a default in >> > > > > > > > runtime/defaults: >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> > > > > > > > >> > > > >> > > > > > > > >> > >> > > > > > > > >> >> > > > > > > > >> > > > > > >> > > > >> > >> quarkus.datasource.jdbc.additional-jdbc-properties.currentSchema=POLARIS_SCHEMA >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > This covers PostgreSQL and CockroachDB >> (the >> > > > shipped >> > > > > > > > >> drivers; >> > > > > > > > >> > H2 >> > > > > > > > >> > > > is >> > > > > > > > >> > > > > >> > test-only), keeps upgrades and the >> > > > out-of-the-box >> > > > > > > > >> experience >> > > > > > > > >> > > > > >> unchanged, >> > > > > > > > >> > > > > >> > and is trivially overridable: pgjdbc >> > documents >> > > > that >> > > > > > > > when a >> > > > > > > > >> > > > property >> > > > > > > > >> > > > > >> is >> > > > > > > > >> > > > > >> > specified both in the URL and in the >> > Properties >> > > > > > object, >> > > > > > > > >> the >> > > > > > > > >> > > > > >> Properties >> > > > > > > > >> > > > > >> > value is ignored [1] — and >> > > > > > additional-jdbc-properties >> > > > > > > > >> > reaches the >> > > > > > > > >> > > > > >> driver >> > > > > > > > >> > > > > >> > through the Properties channel. I >> verified >> > this >> > > > > > > > >> empirically >> > > > > > > > >> > with >> > > > > > > > >> > > > > >> pgjdbc >> > > > > > > > >> > > > > >> > 42.7.13 against both PostgreSQL 17 and >> > > > CockroachDB: >> > > > > > a >> > > > > > > > >> > > > currentSchema >> > > > > > > > >> > > > > >> URL >> > > > > > > > >> > > > > >> > parameter overrides the connection >> property >> > in >> > > > > > both, the >> > > > > > > > >> > property >> > > > > > > > >> > > > > >> alone >> > > > > > > > >> > > > > >> > selects the schema correctly in both, and >> > with >> > > > > > neither >> > > > > > > > set >> > > > > > > > >> > the >> > > > > > > > >> > > > > >> session >> > > > > > > > >> > > > > >> > lands in "public" — which is exactly the >> > silent >> > > > > > failure >> > > > > > > > >> mode >> > > > > > > > >> > the >> > > > > > > > >> > > > > >> shipped >> > > > > > > > >> > > > > >> > default would prevent. (The currentSchema >> > value >> > > > is >> > > > > > also >> > > > > > > > >> > > > case-folded >> > > > > > > > >> > > > > >> like >> > > > > > > > >> > > > > >> > any unquoted identifier on both >> databases, >> > > > > > consistent >> > > > > > > > with >> > > > > > > > >> > the >> > > > > > > > >> > > > > casing >> > > > > > > > >> > > > > >> > behavior we already agreed on.) >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > [1] >> > > > https://jdbc.postgresql.org/documentation/use/ >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > 2. Bootstrap friction for fresh deployments. >> > With >> > > > no >> > > > > > CREATE >> > > > > > > > >> > SCHEMA >> > > > > > > > >> > > > > >> issued >> > > > > > > > >> > > > > >> > by Polaris, even a default fresh >> > installation >> > > > needs >> > > > > > a >> > > > > > > > DBA >> > > > > > > > >> (or >> > > > > > > > >> > > > init >> > > > > > > > >> > > > > >> > script) to run CREATE SCHEMA >> polaris_schema >> > > > before >> > > > > > the >> > > > > > > > >> admin >> > > > > > > > >> > tool >> > > > > > > > >> > > > > can >> > > > > > > > >> > > > > >> > bootstrap. I think the two-step procedure >> > is the >> > > > > > right >> > > > > > > > >> call >> > > > > > > > >> > for >> > > > > > > > >> > > > > >> > production — schema creation is >> privileged >> > DBA >> > > > work >> > > > > > — >> > > > > > > > but >> > > > > > > > >> it >> > > > > > > > >> > does >> > > > > > > > >> > > > > >> add a >> > > > > > > > >> > > > > >> > manual step to every quickstart, >> > > > docker-compose, and >> > > > > > > > Helm >> > > > > > > > >> > > > example, >> > > > > > > > >> > > > > so >> > > > > > > > >> > > > > >> > I'd like the community to explicitly >> bless >> > that >> > > > > > > > trade-off. >> > > > > > > > >> > The >> > > > > > > > >> > > > > >> > getting-started materials would gain an >> init >> > > > step as >> > > > > > > > part >> > > > > > > > >> of >> > > > > > > > >> > the >> > > > > > > > >> > > > > PR. >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > One suggestion to keep the operator UX: the >> > Helm >> > > > > > chart's >> > > > > > > > >> > > > > >> > persistence.relationalJdbc.schemaName value >> > could >> > > > > > stay, but >> > > > > > > > >> > instead >> > > > > > > > >> > > > of >> > > > > > > > >> > > > > >> > mapping to a Polaris property it would >> simply >> > > > render >> > > > > > the >> > > > > > > > >> > > > > >> > additional-jdbc-properties.currentSchema >> > datasource >> > > > > > > > property. >> > > > > > > > >> > > > > Operators >> > > > > > > > >> > > > > >> > keep one discoverable knob; the persistence >> > code >> > > > stays >> > > > > > 100% >> > > > > > > > >> > > > > >> > schema-agnostic. >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > On tests: agreed this is solvable — H2 >> supports >> > > > running >> > > > > > > > >> > > > initialization >> > > > > > > > >> > > > > >> SQL >> > > > > > > > >> > > > > >> > via the INIT= URL parameter (e.g. CREATE >> > SCHEMA IF >> > > > NOT >> > > > > > > > EXISTS >> > > > > > > > >> > ... \; >> > > > > > > > >> > > > > >> > SET SCHEMA ...), which covers schema >> creation >> > and >> > > > > > selection >> > > > > > > > >> for >> > > > > > > > >> > the >> > > > > > > > >> > > > > >> > H2-based tests cleanly. >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > I'll rework the PR accordingly — it's mostly >> > > > deletions >> > > > > > at >> > > > > > > > >> this >> > > > > > > > >> > > > point, >> > > > > > > > >> > > > > >> but >> > > > > > > > >> > > > > >> > we can >> > > > > > > > >> > > > > >> > make additional changes if any disagreements >> > arise. >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > Also, as Yufei mentioned in the PR comment >> > [2], I >> > > > > > believe >> > > > > > > > the >> > > > > > > > >> > > > > community >> > > > > > > > >> > > > > >> has >> > > > > > > > >> > > > > >> > reached a level of consensus high enough for >> > this >> > > > PR >> > > > > > to be >> > > > > > > > >> > moved out >> > > > > > > > >> > > > > of >> > > > > > > > >> > > > > >> > draft >> > > > > > > > >> > > > > >> > state. Moving to your new direction would >> > actually >> > > > > > > > eliminate >> > > > > > > > >> > the new >> > > > > > > > >> > > > > >> > extension point >> > > > > > > > >> > (polaris.persistence.relational.jdbc.schema-name) as >> > > > > > > > >> > > > > >> well. >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > [2] >> > > > > > > > >> > > > > >> > > > > > > > >> >> > > > https://github.com/apache/polaris/pull/4945#discussion_r3583285567 >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > Thanks, >> > > > > > > > >> > > > > >> > Eundo >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > 2026년 7월 16일 (목) 오전 1:47, Alexandre Dutra < >> > > > > > > > [email protected] >> > > > > > > > >> >님이 >> > > > > > > > >> > 작성: >> > > > > > > > >> > > > > >> > >> > > > > > > > >> > > > > >> > > Hi Eundo, >> > > > > > > > >> > > > > >> > > >> > > > > > > > >> > > > > >> > > I did another review and I think things >> are >> > > > shaping >> > > > > > up >> > > > > > > > >> nicely. >> > > > > > > > >> > > > > >> > > >> > > > > > > > >> > > > > >> > > I think though that we need to go one step >> > > > further >> > > > > > and >> > > > > > > > make >> > > > > > > > >> > the >> > > > > > > > >> > > > > whole >> > > > > > > > >> > > > > >> > > JDBC persistence layer completely agnostic >> > of the >> > > > > > schema >> > > > > > > > >> > name. The >> > > > > > > > >> > > > > >> > > schema name can be provided through >> > > > configuration, >> > > > > > using >> > > > > > > > >> > standard >> > > > > > > > >> > > > > >> > > Quarkus configuration properties; the >> Agroal >> > > > > > datasource >> > > > > > > > >> would >> > > > > > > > >> > then >> > > > > > > > >> > > > > >> > > take care of setting the schema on each >> > > > connection. >> > > > > > There >> > > > > > > > >> is >> > > > > > > > >> > > > nothing >> > > > > > > > >> > > > > >> > > to do code-wise. >> > > > > > > > >> > > > > >> > > >> > > > > > > > >> > > > > >> > > This imho eliminates all the issues >> stemming >> > from >> > > > > > > > quoting / >> > > > > > > > >> > casing >> > > > > > > > >> > > > > the >> > > > > > > > >> > > > > >> > > schema names, and makes the code a lot >> more >> > > > portable. >> > > > > > > > >> > > > > >> > > >> > > > > > > > >> > > > > >> > > This approach, of course, makes it >> > impossible for >> > > > > > Polaris >> > > > > > > > >> to >> > > > > > > > >> > > > issue a >> > > > > > > > >> > > > > >> > > CREATE SCHEMA statement on the user's >> > behalf. I >> > > > > > > > understand >> > > > > > > > >> > that >> > > > > > > > >> > > > this >> > > > > > > > >> > > > > >> > > is a breaking change. >> > > > > > > > >> > > > > >> > > But I also think it is a good thing to >> stop >> > > > creating >> > > > > > > > >> schemas >> > > > > > > > >> > on >> > > > > > > > >> > > > the >> > > > > > > > >> > > > > >> > > fly: such a statement should be executed >> by >> > DB >> > > > > > admins, as >> > > > > > > > >> they >> > > > > > > > >> > > > > require >> > > > > > > > >> > > > > >> > > elevated privileges. >> > > > > > > > >> > > > > >> > > >> > > > > > > > >> > > > > >> > > If we agree with this direction, then the >> > > > bootstrap >> > > > > > story >> > > > > > > > >> > becomes >> > > > > > > > >> > > > a >> > > > > > > > >> > > > > >> > > two-step procedure: a DB admin first >> creates >> > the >> > > > > > schema, >> > > > > > > > >> then >> > > > > > > > >> > a >> > > > > > > > >> > > > > >> > > Polaris admin invokes the admin tool to >> > > > bootstrap the >> > > > > > > > >> realm, >> > > > > > > > >> > and >> > > > > > > > >> > > > > >> > > passes the schema to use via Quarkus >> config. >> > > > > > > > >> > > > > >> > > >> > > > > > > > >> > > > > >> > > I'm aware that this may require some >> changes >> > to >> > > > tests >> > > > > > > > using >> > > > > > > > >> > H2, >> > > > > > > > >> > > > but >> > > > > > > > >> > > > > >> > > I'm fairly confident there is a way to >> > > > initialize the >> > > > > > > > >> schema >> > > > > > > > >> > in >> > > > > > > > >> > > > > these >> > > > > > > > >> > > > > >> > > cases. >> > > > > > > > >> > > > > >> > > >> > > > > > > > >> > > > > >> > > Let me know what you think! >> > > > > > > > >> > > > > >> > > >> > > > > > > > >> > > > > >> > > Thanks, >> > > > > > > > >> > > > > >> > > Alex >> > > > > > > > >> > > > > >> > > >> > > > > > > > >> > > > > >> > > On Tue, Jul 14, 2026 at 4:24 AM Eundo Lee >> < >> > > > > > > > >> [email protected]> >> > > > > > > > >> > > > > wrote: >> > > > > > > > >> > > > > >> > > > >> > > > > > > > >> > > > > >> > > > Hi Yufei, >> > > > > > > > >> > > > > >> > > > >> > > > > > > > >> > > > > >> > > > Thanks for the quick action. I've >> updated >> > the >> > > > PR to >> > > > > > > > leave >> > > > > > > > >> > > > > historical >> > > > > > > > >> > > > > >> > > > DDL scripts unchanged. >> > > > > > > > >> > > > > >> > > > >> > > > > > > > >> > > > > >> > > > With regards, >> > > > > > > > >> > > > > >> > > > >> > > > > > > > >> > > > > >> > > > Eundo >> > > > > > > > >> > > > > >> > > > >> > > > > > > > >> > > > > >> > > > 2026년 7월 14일 (화) 오전 1:45, Yufei Gu < >> > > > > > > > [email protected] >> > > > > > > > >> >님이 >> > > > > > > > >> > 작성: >> > > > > > > > >> > > > > >> > > > >> > > > > > > > >> > > > > >> > > > > Hi Eundo, >> > > > > > > > >> > > > > >> > > > > >> > > > > > > > >> > > > > >> > > > > Thanks for the clarification. Just a >> > small >> > > > > > update, >> > > > > > > > the >> > > > > > > > >> > > > > >> --schema-version >> > > > > > > > >> > > > > >> > > > > option has already been removed from >> the >> > > > > > bootstrap >> > > > > > > > >> > command( >> > > > > > > > >> > > > > >> > > > > >> > https://github.com/apache/polaris/pull/5044 >> > > > ), >> > > > > > so I >> > > > > > > > >> don't >> > > > > > > > >> > > > think >> > > > > > > > >> > > > > we >> > > > > > > > >> > > > > >> > > need to >> > > > > > > > >> > > > > >> > > > > update the historical DDL scripts >> > anymore. >> > > > > > > > >> > > > > >> > > > > >> > > > > > > > >> > > > > >> > > > > With that out of the way, I think this >> > PR can >> > > > > > focus >> > > > > > > > on >> > > > > > > > >> > making >> > > > > > > > >> > > > > the >> > > > > > > > >> > > > > >> > > current >> > > > > > > > >> > > > > >> > > > > schema configurable and updating the >> > current >> > > > > > > > bootstrap >> > > > > > > > >> > path >> > > > > > > > >> > > > > >> > > accordingly. >> > > > > > > > >> > > > > >> > > > > >> > > > > > > > >> > > > > >> > > > > Thanks again for working on this! >> > > > > > > > >> > > > > >> > > > > >> > > > > > > > >> > > > > >> > > > > Yufei >> > > > > > > > >> > > > > >> > > > > >> > > > > > > > >> > > > > >> > > > > >> > > > > > > > >> > > > > >> > > > > On Sat, Jul 11, 2026 at 2:01 AM Eundo >> > Lee < >> > > > > > > > >> > [email protected]> >> > > > > > > > >> > > > > >> wrote: >> > > > > > > > >> > > > > >> > > > > >> > > > > > > > >> > > > > >> > > > > > Hi Yufei, >> > > > > > > > >> > > > > >> > > > > > >> > > > > > > > >> > > > > >> > > > > > I was not aware of the discussion >> > regarding >> > > > > > keeping >> > > > > > > > >> the >> > > > > > > > >> > > > latest >> > > > > > > > >> > > > > >> schema >> > > > > > > > >> > > > > >> > > > > > version only. >> > > > > > > > >> > > > > >> > > > > > Thanks for the heads up. >> > > > > > > > >> > > > > >> > > > > > >> > > > > > > > >> > > > > >> > > > > > It seems that you've opened a >> separate >> > > > > > discussion >> > > > > > > > >> > thread on >> > > > > > > > >> > > > > the >> > > > > > > > >> > > > > >> > > removal >> > > > > > > > >> > > > > >> > > > > of >> > > > > > > > >> > > > > >> > > > > > --schema-version >> > > > > > > > >> > > > > >> > > > > > option from the bootstrap command. >> So >> > I'm >> > > > > > guessing >> > > > > > > > >> that >> > > > > > > > >> > the >> > > > > > > > >> > > > > >> removal >> > > > > > > > >> > > > > >> > > > > should >> > > > > > > > >> > > > > >> > > > > > be out of scope >> > > > > > > > >> > > > > >> > > > > > from this PR. >> > > > > > > > >> > > > > >> > > > > > >> > > > > > > > >> > > > > >> > > > > > In that case, in order for the >> polaris >> > > > > > deployment >> > > > > > > > to >> > > > > > > > >> > work >> > > > > > > > >> > > > > as-is >> > > > > > > > >> > > > > >> with >> > > > > > > > >> > > > > >> > > a >> > > > > > > > >> > > > > >> > > > > > configurable schema, >> > > > > > > > >> > > > > >> > > > > > I think we should keep the changes >> to >> > the >> > > > > > > > historical >> > > > > > > > >> DDL >> > > > > > > > >> > > > > >> scripts, and >> > > > > > > > >> > > > > >> > > > > > remove the scripts once >> > > > > > > > >> > > > > >> > > > > > the --schema-version option is >> removed >> > > > from the >> > > > > > > > >> > bootstrap >> > > > > > > > >> > > > > >> command. >> > > > > > > > >> > > > > >> > > > > > >> > > > > > > > >> > > > > >> > > > > > Please feel free to correct me if >> I'm >> > > > wrong. >> > > > > > > > >> > > > > >> > > > > > >> > > > > > > > >> > > > > >> > > > > > Thanks, >> > > > > > > > >> > > > > >> > > > > > >> > > > > > > > >> > > > > >> > > > > > Eundo >> > > > > > > > >> > > > > >> > > > > > >> > > > > > > > >> > > > > >> > > > > > >> > > > > > > > >> > > > > >> > > > > > 2026년 7월 11일 (토) 오전 9:00, Yufei Gu < >> > > > > > > > >> > [email protected]>님이 >> > > > > > > > >> > > > > 작성: >> > > > > > > > >> > > > > >> > > > > > >> > > > > > > > >> > > > > >> > > > > > > Hi Eundo, >> > > > > > > > >> > > > > >> > > > > > > >> > > > > > > > >> > > > > >> > > > > > > Thanks for working on this. Making >> > the >> > > > schema >> > > > > > > > name >> > > > > > > > >> > > > > >> configurable is >> > > > > > > > >> > > > > >> > > a >> > > > > > > > >> > > > > >> > > > > good >> > > > > > > > >> > > > > >> > > > > > > idea. I also agree with Alex that >> we >> > > > should >> > > > > > avoid >> > > > > > > > >> > setting >> > > > > > > > >> > > > > the >> > > > > > > > >> > > > > >> > > schema >> > > > > > > > >> > > > > >> > > > > > every >> > > > > > > > >> > > > > >> > > > > > > time we obtain a connection from >> the >> > > > pool. >> > > > > > > > >> > > > > >> > > > > > > >> > > > > > > > >> > > > > >> > > > > > > I do have one minor concern. I >> don't >> > > > think we >> > > > > > > > need >> > > > > > > > >> to >> > > > > > > > >> > > > touch >> > > > > > > > >> > > > > >> the >> > > > > > > > >> > > > > >> > > > > > historical >> > > > > > > > >> > > > > >> > > > > > > JDBC schemas. We've previously >> > discussed >> > > > on >> > > > > > the >> > > > > > > > dev >> > > > > > > > >> > > > mailing >> > > > > > > > >> > > > > >> list >> > > > > > > > >> > > > > >> > > that >> > > > > > > > >> > > > > >> > > > > > each >> > > > > > > > >> > > > > >> > > > > > > Polaris release should only keep >> the >> > > > latest >> > > > > > > > schema >> > > > > > > > >> > > > version. >> > > > > > > > >> > > > > >> One >> > > > > > > > >> > > > > >> > > small >> > > > > > > > >> > > > > >> > > > > > > behavior change would naturally >> > follow >> > > > from >> > > > > > this. >> > > > > > > > >> We >> > > > > > > > >> > could >> > > > > > > > >> > > > > >> remove >> > > > > > > > >> > > > > >> > > the >> > > > > > > > >> > > > > >> > > > > > > --schema-version option from the >> > > > bootstrap >> > > > > > > > >> command[1]. >> > > > > > > > >> > > > That >> > > > > > > > >> > > > > >> option >> > > > > > > > >> > > > > >> > > > > allows >> > > > > > > > >> > > > > >> > > > > > > users to bootstrap a realm with a >> > > > historical >> > > > > > > > schema >> > > > > > > > >> > > > version. >> > > > > > > > >> > > > > >> While >> > > > > > > > >> > > > > >> > > it >> > > > > > > > >> > > > > >> > > > > may >> > > > > > > > >> > > > > >> > > > > > > be useful in some rare cases, I >> don't >> > > > think >> > > > > > it >> > > > > > > > >> > provides >> > > > > > > > >> > > > > enough >> > > > > > > > >> > > > > >> > > value to >> > > > > > > > >> > > > > >> > > > > > > justify the added complexity. >> > > > > > > > >> > > > > >> > > > > > > >> > > > > > > > >> > > > > >> > > > > > > 1. >> > > > > > > > >> > > > > >> > > > > > > >> > > > > > > > >> > > > > >> > > > > > > >> > > > > > > > >> > > > > >> > > > > > >> > > > > > > > >> > > > > >> > > > > >> > > > > > > > >> > > > > >> > > >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > >> > > > > > > > >> > > > >> > > > > > > > >> > >> > > > > > > > >> >> > > > > > > > >> > > > > > >> > > > >> > >> https://polaris.apache.org/releases/1.6.0/admin-tool/#bootstrapping-realms-and-principal-credentials >> > > > > > > > >> > > > > >> > > > > > > >> > > > > > > > >> > > > > >> > > > > > > Thanks, >> > > > > > > > >> > > > > >> > > > > > > >> > > > > > > > >> > > > > >> > > > > > > Yufei >> > > > > > > > >> > > > > >> > > > > > > >> > > > > > > > >> > > > > >> > > > > > > >> > > > > > > > >> > > > > >> > > > > > > On Thu, Jul 2, 2026 at 2:08 AM >> Eundo >> > Lee >> > > > < >> > > > > > > > >> > > > [email protected] >> > > > > > > > >> > > > > > >> > > > > > > > >> > > > > >> > > wrote: >> > > > > > > > >> > > > > >> > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > Thank you for taking your time >> to >> > > > review. >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > I've applied your suggestion on >> > using >> > > > an >> > > > > > > > explicit >> > > > > > > > >> > > > default >> > > > > > > > >> > > > > >> value >> > > > > > > > >> > > > > >> > > for >> > > > > > > > >> > > > > >> > > > > the >> > > > > > > > >> > > > > >> > > > > > > > helm chart. >> > > > > > > > >> > > > > >> > > > > > > > For other points I agree very >> much >> > with >> > > > > > your >> > > > > > > > >> > direction. >> > > > > > > > >> > > > > >> > > > > > > > However, I just wanted to >> confirm >> > with >> > > > you >> > > > > > the >> > > > > > > > >> > design / >> > > > > > > > >> > > > > >> > > > > implementation >> > > > > > > > >> > > > > >> > > > > > > > details >> > > > > > > > >> > > > > >> > > > > > > > before diving in to create more >> > > > commits. >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > I would greatly appreciate >> > additional >> > > > > > inputs. >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > Thanks, >> > > > > > > > >> > > > > >> > > > > > > > Eundo Lee >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > 2026년 7월 1일 (수) 오후 11:57, >> Alexandre >> > > > Dutra < >> > > > > > > > >> > > > > >> [email protected]>님이 >> > > > > > > > >> > > > > >> > > 작성: >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > > Hi Eundo, >> > > > > > > > >> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > > Thank you for raising this >> topic >> > and >> > > > > > > > providing >> > > > > > > > >> an >> > > > > > > > >> > > > > initial >> > > > > > > > >> > > > > >> draft >> > > > > > > > >> > > > > >> > > > > PR! I >> > > > > > > > >> > > > > >> > > > > > > > > left a few comments. >> > > > > > > > >> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > > I generally agree with the >> idea >> > of >> > > > > > making the >> > > > > > > > >> > schema >> > > > > > > > >> > > > > name >> > > > > > > > >> > > > > >> > > > > > > > > configurable. But I'm not >> sure I >> > > > agree >> > > > > > with >> > > > > > > > >> some >> > > > > > > > >> > > > design >> > > > > > > > >> > > > > >> choices >> > > > > > > > >> > > > > >> > > > > made >> > > > > > > > >> > > > > >> > > > > > > > > in the PR: for example, I >> think >> > it >> > > > would >> > > > > > be >> > > > > > > > >> > easier to >> > > > > > > > >> > > > > let >> > > > > > > > >> > > > > >> the >> > > > > > > > >> > > > > >> > > > > Agroal >> > > > > > > > >> > > > > >> > > > > > > > > pool set the schema on each >> JDBC >> > > > > > connection, >> > > > > > > > >> > rather >> > > > > > > > >> > > > than >> > > > > > > > >> > > > > >> > > having it >> > > > > > > > >> > > > > >> > > > > > set >> > > > > > > > >> > > > > >> > > > > > > > > on each SQL statement >> generated >> > by >> > > > the >> > > > > > > > >> > QueryGenerator. >> > > > > > > > >> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > > Let's keep discussing >> > implementation >> > > > > > details >> > > > > > > > in >> > > > > > > > >> > the PR >> > > > > > > > >> > > > > >> though. >> > > > > > > > >> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > > Thanks, >> > > > > > > > >> > > > > >> > > > > > > > > Alex >> > > > > > > > >> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > > On Wed, Jul 1, 2026 at >> 11:30 AM >> > 이은도 < >> > > > > > > > >> > > > [email protected]> >> > > > > > > > >> > > > > >> wrote: >> > > > > > > > >> > > > > >> > > > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > > > 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 >> > > > > > > > >> > > > > >> > > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > > >> > > > > > > > >> > > > > >> > > > > > > >> > > > > > > > >> > > > > >> > > > > > >> > > > > > > > >> > > > > >> > > > > >> > > > > > > > >> > > > > >> > > >> > > > > > > > >> > > > > >> >> > > > > > > > >> > > > > > >> > > > > > > > >> > > > > >> > > > > > > > >> > > > >> > > > > > > > >> > >> > > > > > > > >> >> > > > > > > > > >> > > > > > > > >> > > > > > >> > > > >> > >> >
