Re: allowing *inheritance* from pgjdbc or pgjdbc-ng ?

I would certainly entertain any changes to pgjdbc-ng to allow this as long as it is properly decoupled and doesn’t cause loads of changes into the driver main.

The ng driver was designed with pluggable protocols as well. So in either case it seems implementing a new implementation of the protocol with the SPI is the obvious direction to go and should leave the the main driver code unchanged.

> On Sep 20, 2015, at 12:42 PM, Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
>
> 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