On 10/05/2014 11:24 AM, Vitalii Tymchyshyn wrote:
> Hello, all
>
> I've made a draft implementation of setFetchSize in autocommit mode
> here: https://github.com/tivv/pgjdbc/tree/autocommit_fetchsize
> Tests look good.
> Note that it does not try to limit Execute size as I don't think I
> understand protocol fully.
I really recommend addressing that part, then.
The protocol is pretty well documented; it doesn't make sense
implementing a new and somewhat complex approach if a simpler one is
possible and might be cleaner.
> The only thing it does is that it does not
> read everything before returning to the caller. Instead it reads
> response rows in fetchSize batches. If another statement tries to use
> the same connection, full result is read immediatelly (this part is not
> tested yet).
I'm still not convinced that reading the result set when the next
statement is run is the right answer.
I'd really like to be able to have the driver return a Runnable or
Future that lets the application assign the reading of the rest of the
result set to a thread, so it can be completed _before_ the app needs to
run another query.
If the current query isn't fully fetched when the next one is run, I'd
prefer to just throw an exception indicating that the previous query
must be fetched. Let the application deal with it. I really don't like
muddling queries together like this.
(That also means exceptions get dispatched in the right place - the
fetch of the prior query).
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services