Thread: fetchsize dynamically changeable?

Given all the other requirements for cursors are met, is it possible to change
the fetchsize on the fly?

e.g.
conn.createStatement(...);
st.setFetchsize(1);
rs=st.executeQuery(...);//we got the first record
st.setFetchsize(10);
rs.next(); //now we got records nr. 2-11 in memory and sit at nr. 2

BTW - how is FETCH BACKWARD, what needs to be done to get it working?

Guido Fiala wrote:
> Given all the other requirements for cursors are met, is it possible to change
> the fetchsize on the fly?
>
> e.g.
> conn.createStatement(...);
> st.setFetchsize(1);
> rs=st.executeQuery(...);//we got the first record
> st.setFetchsize(10);
> rs.next(); //now we got records nr. 2-11 in memory and sit at nr. 2

That should work.

-O

Guido Fiala wrote:

> BTW - how is FETCH BACKWARD, what needs to be done to get it working?

Briefly..

- design a scrollable cursor interface (extensions to QueryExecutor and
perhaps ResultHandler, ResultCursor)

- implement scrollable buffering logic in our ResultSet implementations
(can probably take code from the earlier unapplied
scrollable-cursor-resultset patch)

- implement protocol-specific scrollable cursor logic
  . for the V3 path, this needs the DECLARE+parameters patch I have
pending applied on the server side.
  . there is code in CVS history for analyzing statements and
transforming to DECLARE/FETCH where appropriate

I'm not sure what the split in the buffering logic between
protocol-specific code and abstract resultset code should be. One
approach is to just extend the QUERY_FORWARD_CURSOR style interface to
allow fetching at arbitary absolute locations when
QUERY_SCROLLABLE_CURSOR was specified originally. This is probably simpler.

Another approach is to abstract the storage of result data and have the
high-level code say "give me row number N" and the protocol
implementation deals with buffering and cursor movement implicitly. This
is architecturally nicer, and will better handle things like support for
binary-format resultsets, or even the SPI interface that Thomas
mentioned recently. But it'll be more work.

Also, this needs to be done keeping support for WITH HOLD cursors in
mind. Once the DECLARE/FETCH rewriting code is present, WITH HOLD should
be easy to add..

None of this has been started on, AFAIK.

-O