Message-ID: From: "lukaseder (@lukaseder)" To: "pgjdbc/pgjdbc" Date: Thu, 14 May 2026 13:21:16 +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: lukaseder X-GitHub-Comment-Id: 4451018424 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-4451018424 Content-Type: text/plain; charset=utf-8 > /cc @lukaseder. It would be nice to hear from you as well. Hopefully this should ease struct/array/binary handling with pgjdbc. Thanks for the ping. I think that 2 things would be useful for libraries on top of pgjdbc: - An API to parse / generate the PostgreSQL object notation - Implementation of `SQLInput`, `SQLOutput` as well as `SQLData` support I can only speak on behalf of jOOQ, not other libraries / ORMs, but obviously this has been a bit of a pain to implement in jOOQ. It was done mainly because PostgreSQL is so popular with jOOQ users and so the cost / benefit ratio of implementing both parsers and generators supporting the object notation was worth it. Now that jOOQ already has this, I guess that a pgjdbc implementation won't be of much immediate help as it'll take quite some time until all edge cases are handled correctly, and there might always be an edge case that jOOQ can handle but pgjdbc won't support. Besides, `SQLInput`, `SQLOutput`, and `SQLData` aren't JDBC's best APIs. They leave a lot of open questions for various edge cases, so hacks are necessary, or in case of Oracle, binding to ojdbc specific API that isn't available in JDBC directly. One of the worst flaws of `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. With ojdbc, `ThreadLocal` usage was inevitable from within `SQLData` implementations. > I haven't paid attention to "structs/composites in updateable resultsets". It is yet another todo. I doubt these are still being used a lot. Given that there's talk about deprecating `RowSet` (https://bugs.openjdk.org/browse/JDK-8382268), I wonder edge cases like structs in updatable resultsets should be a priority. `CallableStatement` might be a higher priority, though jOOQ generally doesn't use that API with PostgreSQL compared to just calling a stored function from a SQL query directly.