Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZdnFL-0007Mr-0Q for pgsql-jdbc@arkaria.postgresql.org; Sun, 20 Sep 2015 22:38:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZdnFK-0001pc-DI for pgsql-jdbc@arkaria.postgresql.org; Sun, 20 Sep 2015 22:38:10 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZdnEo-0001GH-U8 for pgsql-jdbc@postgresql.org; Sun, 20 Sep 2015 22:37:39 +0000 Received: from mail-ig0-x22d.google.com ([2607:f8b0:4001:c05::22d]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZdnEh-0001Za-8z for pgsql-jdbc@postgresql.org; Sun, 20 Sep 2015 22:37:37 +0000 Received: by igbni9 with SMTP id ni9so47641894igb.0 for ; Sun, 20 Sep 2015 15:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=EEc4ol3n0k1xd7bKP4XZa1MOB25gv/34boFA9H8hC0U=; b=vK197JH4xIFcv0af+p7Zu+aaFCqJuo9VIoP5WUUvEn+bpdyi3hG9vqvBceZrUmuNkz ERHPJpc963rncGWz5hyMibCFsJ7hMEuyVE7Hsqv1hIL8gDOB9bXOZ+8B1CLZCnYJe66k sjklcQdsAkIp/ZDkwKjB7TQ5GqHZus1aMTqyPdDLXhFPdKhpkwTrq0tIwK6IyRKwoeTk Q48KY5ei4sLnnsRO9EkQ1SlBq8q5rBJzzSgoSzPG+4fPeqlAcrb7rTy5B+befUYGiL87 QoWABzBXXbWvxgH2WVJ0w3jl/bBd7ne+ujzjDZMxXYcYnsxvzdVXyfk5I+C06qBS3TiN NDSg== X-Received: by 10.50.79.164 with SMTP id k4mr7587932igx.16.1442788650203; Sun, 20 Sep 2015 15:37:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.42.69 with HTTP; Sun, 20 Sep 2015 15:37:10 -0700 (PDT) In-Reply-To: References: <55FF0C3A.6070804@anastigmatix.net> From: Dave Cramer Date: Sun, 20 Sep 2015 18:37:10 -0400 X-Google-Sender-Auth: XLemWTJmtm5b-oVG3y67L6GGuAs Message-ID: Subject: Re: allowing *inheritance* from pgjdbc or pgjdbc-ng ? To: Kevin Wooten Cc: Chapman Flack , List , pljava-dev@lists.pgfoundry.org Content-Type: multipart/alternative; boundary=089e01294784fb44050520356830 X-Pg-Spam-Score: -2.4 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-jdbc Precedence: bulk Sender: pgsql-jdbc-owner@postgresql.org --089e01294784fb44050520356830 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 wrote: > I would certainly entertain any changes to pgjdbc-ng to allow this as lon= g > as it is properly decoupled and doesn=E2=80=99t cause loads of changes in= to 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 > 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc > --089e01294784fb44050520356830 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm would say the same. The challenge of course will b= e finding the happy medium

Dave Cramer

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

On 20 September 2015 at 18:34, Kevin Wooten = <kdu= bb@me.com> wrote:
I would = certainly entertain any changes to pgjdbc-ng to allow this as long as it is= properly decoupled and doesn=E2=80=99t cause loads of changes into the dri= ver 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:
>
> 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.<= br> >
> 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 implemente= d
> 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,<= br> > 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 o= f
> 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<= br> > question #1 here.
>
> If the idea works, it could increase the chance we can *share* effort<= br> > 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?=C2=A0 Would converging on the java.util.logg= ing
> 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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

--089e01294784fb44050520356830--