From: thomas at tada.se (Thomas Hallgren) Date: Mon, 21 Sep 2015 08:40:39 +0200 Subject: [Pljava-dev] allowing *inheritance* from pgjdbc or pgjdbc-ng ? In-Reply-To: <55FF6E58.406@anastigmatix.net> References: <55FF1558.9060103@tada.se> <55FF6E58.406@anastigmatix.net> Message-ID: <55FFA667.9090805@tada.se> 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