Content-type: text/plain; charset=windows-1252
MIME-version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: allowing *inheritance* from pgjdbc or pgjdbc-ng ?
From: Kevin Wooten <kdubb@me.com>
In-reply-to: <55FF0C3A.6070804@anastigmatix.net>
Date: Sun, 20 Sep 2015 15:34:56 -0700
Cc: pgsql-jdbc@postgresql.org, pljava-dev@lists.pgfoundry.org
Content-transfer-encoding: quoted-printable
Message-id: <AA7C9244-83EA-40D2-ACE2-2E1DAA3179FA@me.com>
References: <55FF0C3A.6070804@anastigmatix.net>
To: Chapman Flack <chap@anastigmatix.net>
Precedence: bulk
Sender: pgsql-jdbc-owner@postgresql.org

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

The ng driver was designed with pluggable protocols as well. So in either c=
ase 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 u=
nchanged.

> On Sep 20, 2015, at 12:42 PM, Chapman Flack <chap@anastigmatix.net> wrote:
>=20
> Hi,
>=20
> I've been putting some work recently into PL/Java.
>=20
> 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.
>=20
> 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!"
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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?
>=20
> I guess that's enough for now, thanks for your attention.
>=20
> -Chap


--=20
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc