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

On 2015-09-21 04:41, Chapman Flack wrote:
> Thomas Hallgren wrote:
>> 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.
> I am thinking (perhaps naively for now, as I haven't written any code
> yet) that this can be achieved. In the pgjdbc case, what the visible
> API-implementing classes wrap is an
> org.postgresql.core.ProtocolConnection (an interface, responsible for
> the actual communication with the database). That interface is
> implemented by v3 or v2 frontend-backend ProtocolConnectionImpl
> classes, and yes, _they_ stream data. But there's really nothing
> about the ProtocolConnection interface itself that seems to rule out
> providing another class that implements it and uses SPI.
>
> https://github.com/pgjdbc/pgjdbc/blob/master/org/postgresql/core/ProtocolConnection.java
>
> sendQueryCancel(), maybe. And we probably just don't care about that
> one. :)
We definitely do not care about that one since using it would imply using more than one thread.

> The ProtocolHandler is what gives you a QueryExecutor instance.
> So naturally a PLJavaSPIProtocolConnection would give you a
> PLJavaSPIQueryExecutor. I'm not quite sure yet who instantiates
> implementations of ResultCursor, but that's just a matter of reading
> the code more. Is this starting to sound like it could turn out to be
> possible to do what we want?
Yes. I haven't been into these details for quite some time (as you might notice :-) ). This is starting to make a lot of
sense. Watch out for threads though. PL/Java *must* use the caller thread when accessing the SPI layer.

- thomas