Vladimir Sitnikov

packaging scripts should be updated as well to accomodate for the new scram dependency name: https://github.com/pgjdbc/pgjdbc/blob/5e3190d5f3ad667a42210bee881b04404332cf30/packaging/rpm/postgresql-jdbc.spec.tpl#L67 Currently, Fedora builds fail as follows: https://download.copr.fedorainfracloud.org/results/@pgjdbc/pgjdbc-ci/fedora-39-x86_64/07784881-postgresql-jdbc/builder-live.log.gz ``` [INFO] ---------------------< org.postgresql:postgresql >---------------------- [INFO] Building...

@jorsol , would you please update postgresql-jdbc.spec.tpl as well?

Of course, the PR would be welcome. I'm not sure if the implementation would be complicated or not though. It would be hard to test the network roundtrip is non-existent,...

>simple to just add a "cachedParamterMetadata" field to the PgPreparedStatement I think it should be slightly more complicated. Of course, it would cover a case when the same `PgPreparedStatement` object...

> In contrast, caching in the preparedStatement itself would be essentially free of downsides Consider the following ```sql create table users( id number, name varchar(100) ) ``` ```kotlin var con:...

>At least then it's consistent with itself? Well, currently we do cache `server-prepared statements` **across** `PgPreparedStatement` objects, so caching parameter metadata, in the same way, seems natural.

I added more tests in https://github.com/pgjdbc/pgjdbc/commit/fad7c5646bf90c279646eb3350bcdc0aa6b3326f#diff-782874e21dce2e67efceee1a11f94649eb5109134bb4fb3a4c13d487378725c1R1469, and it turns out that `parameterMetaData` depends on the `ps.set(...)` calls. So the cache should be like "query + currentParameterTypes => actualParameterTypes"

@rutchkiwi , I learnt that the hard way as I tried implementing "parameter metadata" cache recently. Here's my work-in-progress branch: https://github.com/vlsi/pgjdbc/tree/parameter_metadata, however, I haven't added "known-type-dependent cache" yet. Here are...

I believe the core of the issue is that `Apache Http Client` adds the excessive encoding header: https://github.com/apache/httpcomponents-client/blob/54900db4653d7f207477e6ee40135b88e9bcf832/httpmime/src/main/java/org/apache/http/entity/mime/MultipartEntityBuilder.java#L215-L217 However, it does use the provided in `multipartEntityBuilder.setCharset(charset);` charset in https://github.com/apache/httpcomponents-client/blob/54900db4653d7f207477e6ee40135b88e9bcf832/httpmime/src/main/java/org/apache/http/entity/mime/MultipartEntityBuilder.java#L228 =>...

> Or perhaps JMeter shouldn't invoke setCharset? As I said earlier, `MultipartEntityBuilder.setCharset` was needed there for `HttpBrowserCompatibleMultipart.java` to work, as there's no other option to configure charset for `HttpBrowserCompatibleMultipart` mode...