Message-ID: From: "vlsi (@vlsi)" To: "pgjdbc/pgjdbc" Date: Thu, 14 May 2026 14:07:47 +0000 Subject: Re: [pgjdbc/pgjdbc] PR #3062: feat: type cache rework, codec API, and composite-type round-trip In-Reply-To: References: List-Id: X-GitHub-Author-Login: vlsi X-GitHub-Comment-Id: 4451408205 X-GitHub-Comment-Type: issue_comment X-GitHub-Issue: 3062 X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-Type: comment X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/3062#issuecomment-4451408205 Content-Type: text/plain; charset=utf-8 > I guess that a pgjdbc implementation won't be of much immediate help Do you mean you generate and parse **binary** encodings for composites/arrays as well? I'm quite sure binary should be significantly faster as it would avoid 2^N (?) quoting degradation when sending nested structs that include text fields with quotes. Well. Not being force to quote contents should be a noticeable win on its own. > `SQLInput`, `SQLOutput` They are implemented as well. > SQLData is that neither SQLInput nor SQLOutput expose a JDBC Connection or some other context object allowing for creating / reading JDBC types, such as arrays Will add as a TODO. It is indeed sad to have `SQLOutput.writeStruct(Struct)` without being able to instantiate one. >I wonder edge cases like structs in updatable resultsets should be a priority 10 min of claude fixed the issue and added binary encoding as well (previously, updateable resultsets were text-only) 🤷 > CallableStatement might be a higher priority Callable seems to be fixed as well > it'll take quite some time until all edge cases are handled correctly Right you are. I wonder if you could try pgjdbc with jOOQ tests to see if there's a regression.