Subject: [pgjdbc/pgjdbc] PR #3369: fix: EOFException on PreparedStatement#toString with unset bytea parameter since 42.7.4

From: "MrEasy (@MrEasy)" <[email-masked]>
Date: Thu, 29 Aug 2024 13:46:06 +0000

Test case reproducing issue of #3365.
Fix by @kimjand

---

From: "MrEasy (@MrEasy)" <[email-masked]>
Date: Mon, 09 Dec 2024 08:08:03 +0000

> Could you keep the old method names and signatures?

@kimjand added a method, that differs from existing one (see javadoc), not sure what you @vlsi mean with keeping the old names?

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Thu, 20 Mar 2025 10:47:35 +0000

> @kimjand added a method, that differs from existing one (see javadoc), not sure what you @vlsi mean with keeping the old names?

Instead of using toStringLiteral() use toString()

---

From: "MrEasy (@MrEasy)" <[email-masked]>
Date: Thu, 20 Mar 2025 13:32:34 +0000

>From javadoc, I'd assume this was on purpose. @kimjand could you comment on this?

Would be great if we can get the fix into next release, as this blocks our update to recent versions.

---

From: "kimjand (@kimjand)" <[email-masked]>
Date: Thu, 20 Mar 2025 15:45:55 +0000

On 20-03-2025 14:32, Rico Neubauer wrote:
>         @kimjand <https://github.com/kimjand> added a method, that
>         differs from existing one (see javadoc), not sure what you @vlsi
>         <https://github.com/vlsi> mean with keeping the old names?
> 
>  From javadoc, I'd assume this was on purpose. @kimjand <https:// 
> github.com/kimjand> could you comment on this?
> 

Yes, this was completely intentional. The core of this bug is that the 
driver can't decide on what the methods are supposed to do. ToString 
claims it provides human readable output, but the driver expects it to 
contain literals for the parameter values.
Now there is a clear distinction between the two cases.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Thu, 24 Apr 2025 20:29:02 +0000

I'm working on this. Please let me have a couple of days more

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Thu, 15 May 2025 07:57:43 +0000

(on pgjdbc/src/main/java/org/postgresql/core/v3/CompositeQuery.java)

This still looks like a bug. The input `parameters` are not used at all. So `toString()` would be the same as `toExecutableSql()`, so there's no point in having `if` here.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Thu, 15 May 2025 14:32:19 +0000

Looks like for `toString` we need the following:

```java
@Nullable ParameterList params; // optional
boolean standardConformingStrings;
boolean idempotent; // == skipInputStreams
```

I wonder if we use an interface for it instead of (boolean, boolean) parameters?

Currently we have

```java
String toString(@Nullable ParameterList params, boolean standardConformingStrings);
String toExecutable(@Nullable ParameterList params, boolean standardConformingStrings);
```

What if we go for the following?

```java
interface SqlContext {
  boolean getStandardConformingStrings();
  boolean getIdempotent();
}

@Deprecated
String toString(@Nullable ParameterList params, boolean standardConformingStrings);

String toString(@Nullable ParameterList params, SqlContext context);
```

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Thu, 15 May 2025 16:59:55 +0000

(on pgjdbc/src/main/java/org/postgresql/core/v3/SqlSerializationContext.java:11)

@bokken , @sehrope , WDYT of this?
I'm not sure regarding the name, however, I like the interface approach better than two methods `toString` and `toExecutableSql`.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Fri, 16 May 2025 12:03:38 +0000

I'm happy with the current state of the PR.
Reviews are welcome.
Will merge the PR in a couple of days.

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Tue, 20 May 2025 14:09:07 +0000

I like this idea

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Tue, 20 May 2025 14:11:52 +0000

(on pgjdbc/src/main/java/org/postgresql/core/Query.java)

`so it should not be used only once` seems wrong ... did you mean `so it should only be used once` ...

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Tue, 20 May 2025 14:11:57 +0000

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Tue, 20 May 2025 14:20:58 +0000

(on pgjdbc/src/main/java/org/postgresql/core/v3/DefaultSqlSerializationContext.java:17)

I think it would be useful to document why and where each of these are used.
For instance we use IDEMPOTENT to send the query to the backend
STD is standard conforming strings which is a setting in the backend.

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Wed, 21 May 2025 12:33:43 +0000

Good catch. The doc was outdated as the behaviour is configurable via `SqlSerializationContext` parameter. I will drop the note and add `@param context specifies configuration for converting the parameters to string`

---

From: "vlsi (@vlsi)" <[email-masked]>
Date: Wed, 21 May 2025 12:47:27 +0000

I've added the doc to the enum entries

---

From: "davecramer (@davecramer)" <[email-masked]>
Date: Wed, 21 May 2025 15:02:37 +0000

LGTM