Subject: [pgjdbc/pgjdbc] PR #4063: fix: getCharacterStream wraps String in StringReader

From: "dfa1 (@dfa1)" <[email-masked]>
Date: Sun, 10 May 2026 06:01:48 +0000

Previously returned new CharArrayReader(value.toCharArray()), which allocates a char[] proportional to the string length (2 * n bytes). StringReader wraps the String directly with no extra allocation.

No benchmark written: the allocation is trivially O(n) and the fix is mechanical. Visible in -prof gc as reduced char[] allocation under any workload that calls getCharacterStream().

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Sun, 10 May 2026 10:07:36 +0000

The only challenge here is that this while doesn't break the API, it does materially change what is returned. This would be a breaking change.

---

From: "dfa1 (@dfa1)" <[email-masked]>
Date: Sun, 10 May 2026 12:34:51 +0000

Would a changelog entry ("getCharacterStream now returns StringReader; callers should rely on the Reader contract as per JDBC spec") be enough to address it?  Alternatively I could extend the PR to make this opt-in change (but I would need guidance for the best mechanism).

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Sun, 10 May 2026 20:00:23 +0000

For sure needs a change log entry.  The question is will it require a major version? We've released what we thought were harmless minor versions only to find out it broke something somewhere

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Sun, 10 May 2026 20:03:51 +0000

Why major version? The change is subtle, and the return type is still Reader. I think patch version is fine

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Sun, 10 May 2026 20:14:34 +0000

Agreed it is a Reader, but if someone actually casts it to CharArrayReader in their code then it will break their code.
That said I could be convinced otherwise as it does meet the API

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 11 May 2026 07:56:48 +0000

> if someone actually casts it to CharArrayReader in their code then it will break their code

That is fair. `CharArrayReader` has been sitting there since 2002.

On the other hand, `CharArrayReader` adds no new methods, and its `char[] buf` is protected, so I am leaning towards patch-level change. If we treat this as minor, then we would have to bump minor in virtually every change we make, which would render "minor bump" useless for the users.

Frankly, I see two options:

* We could consider this as an internal/bugfix/almost backward-compatible change. In that case we just fix it.
* We could consider this as a user-visible/non backward-compatible change. In that case we should rather add an option to allow users switching to the new default, and after 2 years we could flip the default.

I would accept either way (we shouldn't spent time on discussing the trivial changes), however, I would prefer just fix it as it is unlikely to break users' code.

---

There's yet another possibility: the resultset holds `byte[]` + `encoding`. @dfa1 , have you evaluated/profiled the approach of using `new InputStreamReader(new ByteArrayInputStream(bytes), charset)` approach?

---

From: "sehrope (@sehrope)" <[email-masked]>
Date: Mon, 11 May 2026 11:24:11 +0000

Changing the class while still returning a `Reader` is not a breaking change. Anybody that is relying on the exact underlying implementation has been gambling that it will never change. And that user must have been explicitly casting the reader type too. So I doubt this is a problem in the real world and even if it is, it's the user's problem to fix.

This is a purely internal change and does not require maintaining any backwards compatible flag for the old behavior. If we want the change, just change the returned value and that's it.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Mon, 11 May 2026 11:26:01 +0000

I'm just exercising caution. We have been here before. I'm not a proponent of adding yet another configuration option so I will stop arguing against this.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Mon, 11 May 2026 11:27:27 +0000

@dfa1 Can you add something to the Changelog and I will merge it.

---

From: "dfa1 (@dfa1)" <[email-masked]>
Date: Mon, 11 May 2026 18:46:00 +0000

@davecramer  please have a look now

@vlsi  @sehrope  thanks for the review!

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 11 May 2026 19:36:01 +0000

(on CHANGELOG.md:112)

What was the reason to modify the lines? Please do not mix unrelated changes into the PR.

---

From: "dfa1 (@dfa1)" <[email-masked]>
Date: Mon, 11 May 2026 19:43:41 +0000

(on CHANGELOG.md:112)

sorry that is my editor configured to trim trailing spaces automatically

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Mon, 11 May 2026 19:50:22 +0000

(on CHANGELOG.md:112)

Spaces at the end of lines are **significant** for markdown. We have .editorconfig so editors that support it configure automatically