[Pljava-dev] allowing *inheritance* from pgjdbc or pgjdbc-ng ?

Hi Chap,

One major (perhaps the major) reason for the current design was to avoid streaming data. The current SPIResultSet reads
its data directly from the Tuple provided from SPI. Writing it to a stream, just to then parse it again in the same
process (and same thread), will undoubtedly result in some overhead. Especially when dealing with large binary objects
and/or large result sets.

PL/Java is all about closeness to the data. If you remove the advantages gained by that closeness, then why not use Java
in the client instead?

That said, I fully sympathize with the motivating factors that you bring up. Then again, the JDBC interfaces doesn't
change that often and when they do, the changes tend to be manageable. I'm not sure I agree that it's worth sacrificing
performance to make them easier to maintain.

Basically it all boils down to what the performance implications are. If you have a solution that words well enough to
test that and produce some numbers, then I think that would be a great input.

- thomas

On 2015-09-20 21:42, 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
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev