jOOQ custom data types for pl/java UDT

Here's something I sent last year but missed the bounce message due to
having an outdated mailing list. It's pretty advanced but it might be worth
a few paragraphs after the discussion of creating UDTs. If I understand it
correctly it's not hard to imagine a setup where there's one maven module
that defines the java class, one module that provides the classes used in
the UDT based on that class, and a second module that provides the classes
used by jOOQ based on the same class. To the developer the representation
will be entirely transparent since jOOQ can handle the necessary
conversions. That should make it easier fo developers to push logic into
the database - why retrieve 1000 records if you then filter them to find
just one if you can perform the filtering on the database since the UDT
uses the same implementation?

However I'm not 100% sure of this since I don't know if a UDT can be
treated as a BLOB. Maybe it requires registration of a few additional
methods, maybe it requires registration UDF to handle conversion between
the UDT and a blob.

----

Here's something that should be gussied up and added to the pl/java
documentation (somewhere...) - jOOQ custom data types for pl/java UDT.

jOOQ is a framework that provides a database-agnostic implementation of
SQL. Unlike many similar projects the guy clearly knows his **** and is
able to take your fluent translation of SQL and quietly implement missing
functionality (e.g., adding a merge()) or perform some optimizations.

One of the lesser-known features is the support for user-defined types via
converters and bindings. (See
https://www.jooq.org/doc/latest/manual/code-generation/custom-data-type-bindings/)
Basically a "converter" operates on standard values already received by
jOOQ (e.g., a Base64 encoded string) and "binding" operates at the JDBC
level (e.g., converting a Timestamp to an Instance - the standard jOOQ code
goes through java.time and loses the milliseconds.) You can use them to
define a DataType<T> which is treated identically to the native types.

This is relevant to pl/java since anyone writing a pl/java extension is
probably also accessing the database via a java application. With a bit of
maven juggling you can have one project (with possibly multiple modules)
define a java UDT that's kept in sync between java application and database
with transparent persistence. You can probably do the same thing in other
frameworks (e.g., Spring Data) and languages but I'm not as familiar with
them.

One of the other benefits is a jOOQ tool that uses inspection of database
metadata to generate the source code for the corresponding jOOQ tables. I'm
pretty sure there's also a way to convert SQL into the corresponding fluent
java expression. If it already has a DataType<T> that matches your pl/java
UDT it will automatically use your java class in the generated code -
there's no need for you to worry about the implementation details as a user.

I know this is beyond the scope of *just* a server-side extension but I
wanted to mention it allows us to hide the details required on the java
side. The user doesn't need to know to call getBlob() and then some
conversion method - they can continue working in at least one high level
abstraction and without needing to do much more than add an additional jar
to their classpath.

Bear