Message-ID: <gh-pgjdbc-pgjdbc-3062-c4485378187@github.com>
From: "lukaseder (@lukaseder)" <noreply+lukaseder@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Tue, 19 May 2026 07:24:36 +0000
Subject: Re: [pgjdbc/pgjdbc] PR #3062: feat: type cache rework, codec API, and composite-type round-trip
In-Reply-To: <gh-pgjdbc-pgjdbc-3062@github.com>
References: <gh-pgjdbc-pgjdbc-3062@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: lukaseder
X-GitHub-Comment-Id: 4485378187
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-4485378187
Content-Type: text/plain; charset=utf-8

> The driver needs to describe the query to know the resultset shape.
> When the driver knows the column types, it can request binary encoding for the types it can decode.

Ah, I get it now. That's really interesting, then! Might speed up a few queries for jOOQ users, if we switched to the `SQLData` API, when fetching heavily nested UDTs. For dynamic types (`ROW()`, `MULTISET()`), jOOQ defaults to `JSONB` serialisation, so I wouldn't expect massive performance gains, but for UDTs, definitely.

I'll try to work with your branch, later this week. If your branch gets merged, we can have an experimental, opt-in implementation in jOOQ that users could activate with a switch. I'd expect that this could greatly help increase test coverage for you as well.

Just so I understand, `BINARY_TRANSFER_ENABLE` is only affecting binary transfer (i.e. pgjdbc looking up type structures). Even if this flag isn't set, `SQLData` can be used for all types, with more overhead?