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

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Dave Cramer <[email protected]>
To: Kevin Wooten <[email protected]>
Cc: Chapman Flack <[email protected]>
Cc: List <[email protected]>
Cc: [email protected]
Subject: Re: allowing *inheritance* from pgjdbc or pgjdbc-ng ?
Date: Sun, 20 Sep 2015 18:37:10 -0400
Message-ID: <CADK3HH+Xyt7NMxrhJSpDvzj9T3uDbhHjEjbZeT-w+96Lq+eOZw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-jdbc>

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 <[email protected]> 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 <[email protected]>
> 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 ([email protected])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>

view thread (6+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: allowing *inheritance* from pgjdbc or pgjdbc-ng ?
  In-Reply-To: <CADK3HH+Xyt7NMxrhJSpDvzj9T3uDbhHjEjbZeT-w+96Lq+eOZw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox