Brett Okken

> 2\. Factor common types to a read-only part. In other words, we know common types for the base PostgreSQL, so we could have a single cache with base types...

We could expose some proprietary executeBatch which returns an aggregate sum. It is not obvious to me anyway to do a rewrite and provide a valid api response. On Wed,...

@vlsi - I think we are saying same thing. @sehrope i do not believe we should change the current jdbc spec api reply. All of the proposed solutions do not...

I still have the questions from the issue: https://github.com/pgjdbc/pgjdbc/issues/3170#issuecomment-2027245467

The problem is that the same logical context can be represented in multiple ways. The most obvious example is string vs binary representation. My question about executing 10 selects in...

There are multiple string representations which are logically equal. This is a significant part of why I do not believe that implementing equals and hashCode for PgArray is appropriate. On...

@marschall, I completely agree that the postgresql TIMESTAMP type has complicated mappings into java data types. I guess in light of the inconsistencies I prefer to take the approach of...

`Timestamp` as a data type is not bound the the jvm time zone. The jdbc api for setTimestamp and getTimestamp have specified the use of the default timezone when no...

> As you can see the time java.sql.Timestamp -> java.time.Instant conversion depends on the JVM default time zone. I am not sure I agree. What I see is that `LocalDateTime`...

Is providing support for (getting) OffsetDateTime and ZonedDateTime by always interpreting as UTC really valuable? I understand the desire to be liberal in datatype mappings supported, but the lack of...