allowing *inheritance* from pgjdbc or pgjdbc-ng ?

Hi,

I've been putting some work recently into PL/Java.

It provides a direct JDBC interface for Java code on the backend,
using SPI under the hood. The JDBC code was clearly copy/pasted from
pgjdbc long ago, then adapted to the needs of running on the backend.

I'll be preaching to the choir if I say upkeep of a JDBC interface
is a lot of work. Easy or hard new workloads at any time can be dumped
onto the project from either end. New PostgreSQL release? New protocol
details, metadata queries, etc., have to be worked out, and somebody
has to do that. New Java release? New JDBC interfaces to be implemented
and figured out, and somebody has to do that. And with the copied/
pasted code, somebody has to do that for pgjdbc *and* somebody has
to do it for PL/Java, and I'm sure neither project has so many
committers as to say "hey, no problem, we love duplicating work,
gives us something to do!"

What I would really like to experiment with is how possible it
might be for PL/Java to provide JDBC by *inheritance* from pgjdbc
(or pgjdbc-ng) instead of by copy and paste. Add a dependency to
the Maven pom and it's off to the races.

I'm sure the devil is in all the little things I can't think of
up front, but in dreamland it basically works by having some way
to instantiate a Jdbc...Connection with a different underlying
ProtocolConnection subclass (one that uses SPI instead of v2 or v3,
returns TRANSACTION_OPEN from getTransactionState() at all times,
returns its own kind of QueryExecutor, etc.). I'm using the pgjdbc
names here.

Whether to try with pgjdbc or pgjdbc-ng, I don't know. The first
might be easier because of the original code similarity. The second
might be easier because the code is new and streamlined. It looks like
in either case, I would need to submit a few pull requests upstream
just to make it possible to instantiate and subclass the necessary
things with a different connection subclass.

If I made some pull requests of that sort, would you (pgjdbc or
pgjdbc-ng) be generally open to considering them? That's my basic
question #1 here.

If the idea works, it could increase the chance we can *share* effort
on improvements that benefit two projects, instead of just going on
making the same improvements twice.

Another plus on the PL/Java side could be that, if someone had backend
code with some reason to connect to another database, or have a side
connection to the same one, the same JDBC implementation would already
be there, just using a remote connection URL instead of
jdbc:default:connection, and the behavior would be as consistent as
possible given the different connection properties.

After question #1 I may have some smaller ones, one I can think of
is about logging. PL/Java and pgjdbc-ng both use java.util.logging,
pgjdbc has a homegrown org.postgresql.core.Logger, for historical
reasons I'm guessing? Would converging on the java.util.logging
API be a thinkable thought, or just way too much work, or
objected to for some philosophical or technical reason?

I guess that's enough for now, thanks for your attention.

-Chap