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 > > > > > > >> > > > > >> > > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > > >> > > > > >> > > > > > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > >> > > > > > > > > >> > > > > >> > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > >
