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

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Kevin Wooten <kdubb(at)me(dot)com>
Cc: Chapman Flack <chap(at)anastigmatix(dot)net>, List <pgsql-jdbc(at)postgresql(dot)org>, pljava-dev(at)lists(dot)pgfoundry(dot)org
Subject: Re: allowing *inheritance* from pgjdbc or pgjdbc-ng ?
Date: 2015-09-20 22:37:10
Message-ID: CADK3HH+Xyt7NMxrhJSpDvzj9T3uDbhHjEjbZeT-w+96Lq+eOZw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc pljava-dev

I'm would say the same. The challenge of course will be finding the happy
medium

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 20 September 2015 at 18:34, Kevin Wooten <kdubb(at)me(dot)com> wrote:

> 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
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Chapman Flack 2015-09-21 02:41:28 [Pljava-dev] allowing *inheritance* from pgjdbc or pgjdbc-ng ?
Previous Message Kevin Wooten 2015-09-20 22:34:56 Re: allowing *inheritance* from pgjdbc or pgjdbc-ng ?

Browse pljava-dev by date

  From Date Subject
Next Message Chapman Flack 2015-09-21 02:41:28 [Pljava-dev] allowing *inheritance* from pgjdbc or pgjdbc-ng ?
Previous Message Kevin Wooten 2015-09-20 22:34:56 Re: allowing *inheritance* from pgjdbc or pgjdbc-ng ?