On 10-12-2014 22:22, Dmitry Yemanov wrote: > At the moment, I can think of a simple solution: > > a) limit server-side batch size calculation to the FB3 protocol (and > later) -- thus avoiding any compatibility issues
I think this is a sufficient solution. However if you look at how JDBC is defined then an option to control the fetchsize is a nice to have. > b) within the FB3 protocol (and later), allow the client to explicitly > ask for unknown (server-decided) number of rows As I said: a nice to have. Especially in higher latency environments, it might be better to be able to request (and get) more rows then the default calculation. > And I need opinions on (b). I don't really want to extend the op_fetch > packet with more fields. Do you think it would it be OK to reserve some > special values for p_sqldata_messages to indicate this? Zero? ULONG(-1)? I'd say zero (0), but just because it fits nicely with the JDBC definition of [setFetchSize(int)][1]: "Gives the JDBC driver a hint as to the number of rows that should be fetched from the database when more rows are needed for ResultSet objects generated by this Statement. If the value specified is zero, then the hint is ignored. The default value is zero." Mark [1]: https://docs.oracle.com/javase/8/docs/api/java/sql/Statement.html#setFetchSize-int- -- Mark Rotteveel ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
