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