Vladimir Sitnikov
Vladimir Sitnikov
On the other hand, if the changes could be cherry-picked, then it might be worth doing so.
> I think biggest optimization would be to replace FilterOutputStream with custom delegate. FilterOutputStream writes to given OutputStream one byte at a time I think `BuferredOutputStrem` overrides `write(byte[], int, int)`...
> Looking at PGStream more closely, it might make sense to move logic from sendInteger2 etc. to OutputStream That sounds plausible. > I'll add the modified benchmark. Frankly, I suggest...
Is this still relevant? I guess generate_series should be removed at least from "lookup type by name", see https://github.com/pgjdbc/pgjdbc/pull/3244
A key factor here is "planning time", so we could probably improve the thing a lot if we apply prepared statements.
+1 for deprecating jakarta's `@Nullable`: * Jakarta's nullable does not work with generics. One can't use jakarta's annotation like `List`. I have annotated [Apache Calcite](https://github.com/apache/calcite) and [pgjdbc](https://github.com/pgjdbc/pgjdbc) with machine-verifiable nullability,...
git blame would not be impacted at all as we could add it as yet another commit to https://github.com/pgjdbc/pgjdbc/blob/master/.git-blame-ignore-revs
If we add such a connection property, then it might be considered a CVE. For instance, we had to remove a property for log configuration.
Could you please measure the performance before and after the change?
Please add a test that verifies a case when client uses different bind types for "the same" statement. For example: ```java String sql = "select * from inttable where a...