Обсуждение: Re: idea to have driver return immediately after a query

Oliver Jowett  wrote:

> What happens if the app then wants to run another query before
> reading the resultset?

Some JDBC drivers I've used do read the entire original ResultSet
into the heap when that happens.  If we redo the protocol, there
would probably be a way to design a better solution.

> I'm a little worried about error handling too.

Any code written for portability would deal with it, since most
drivers stream the results and can throw exceptions on next().  (It
is declared to throw that in the interface, after all.)  I don't know
whether there is PostgreSQL specific code with assumes that the
declared exception won't happen, but if that's a significant issue,
it could be solved by supporting both techniques and adding a
connection property.  I before going that far, I'd want to ensure
someone actually needed that, though.

-Kevin

On 28 March 2011 02:42, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote:
> Oliver Jowett  wrote:
>> I'm a little worried about error handling too.
>
> Any code written for portability would deal with it, since most
> drivers stream the results and can throw exceptions on next().  (It
> is declared to throw that in the interface, after all.)

Sure, we do that too already when a fetchsize is set.
I was more worried about problems similar to this:

  ResultSet rs1 = statement1.executeQuery();
    // send Parse, Bind, Execute
    // process parse, bind responses (all OK)
    // return control to the caller
  ResultSet rs2 = statement2.executeQuery();
    // need to read statement1's pending results first
    // oops - actually, statement1's query deadlocked, how do we
report that error sensibly?

If we don't ensure that the connection is in an idle state when we
return control to the caller, it's going to be hard to report errors
in the right context.

Oliver