Nic wrote:
> Fernando Nasser <fnasser@redhat.com> writes:
>
>
>>>+
>>>+ <para>Changing code to cursor mode is as simple as setting the
>>>+ fetch size of the <classname>Statement</classname> to the
>>>+ appropriate size. Setting the fecth size back to 0 will cause
>>>+ all rows to be cached (the default behaviour).
>>>+
>>
>>
>>Perhaps you should mention the retrieval all rows must happen inside a
>>transaction. The cursor that is created is not HOLD or anything.
>
>
> Ok. I'll do that.
>
>
>
>>>+<programlisting>
>>>+Statement st = db.createStatement();
>>>+// Turn use of the cursor on.
>>>+st.setFetchSize(50);
>>>+ResultSet rs = st.executeQuery("SELECT * FROM mytable");
>>>+while (rs.next()) {
>>>+ System.out.print("a row was returned.");
>>>+}
>>>+rs.close();
>>>+// Turn the cursor off.
>>>+st.setFetchSize(0);
>>>+ResultSet rs = st.executeQuery("SELECT * FROM mytable");
>>>+while (rs.next()) {
>>>+ System.out.print("many rows were returned.");
>>>+}
>>>+rs.close();
>>>+// Close the statement.
>>>+st.close();
>>>+</programlisting>
>>>+ </para>
>>>+
>>>+
>>
>>
>>I do not understand what the example is supposed to show. The fetch
>>size is transparent to the user (it is just a hint to the driver about
>>what should be the best strategy) so you should be able to get all the
>>rows, and the same number of them, as you go doing rs.next().
>
>
> The example is supposed to show that you get different behaviour with
> different values. The latency on the first call with be lower (with
> large result sets) than the latency on the second call.
I'm confused: this appears to say that setFetchSize() now works in some
version of PG JDBC. As of the JDBC that builds with PG 7.3.3,
setFetchSize() claims it's "unimplemented." Also, this looks like
straight client-side Java code; what's the "stored procs" part of the
patch? We don't have Java inside PG yet, do we?
REC
