Hi, all,
Thanks for many comments and information. First, let me make consensus on the interpretation of JDBC spec.
The value given to setFetchSize() is a hint, not the actual number of rows. The default hint is 0. e.g. The Java SE 7
APIdoc says:
"Gives the JDBC driver a hint as to the number of rows that should be fetched from the database when more rows are
neededfor ResultSet objects genrated by this Statement. If the value specified is zero, then the hint is ignored. The
defaultvalue is zero."
On the other hand, the JDBC spec and the API doc say different thing regarding the return value of getFetchSize(). The
JDBCdoc says that it returns the hint value, while the API doc says that it returns the number of rows (not the hint).
[JDBC spec]
"The methods getFetchDirection and getFetchSize return the current value of the
hints. If either of these methods is called before the corresponding setter method has
been called, the value returned is implementation-defined."
[Java SE 7 API doc]
"Retrieves the number of result set rows that is the default fetch size for ResultSet objects generated from this
Statementobject. If this Statement object has not set a fetch size by calling the method setFetchSize, the return value
isimplementation-specific."
However, the API doc should be correct. If the return value were the hint value, it should be 0 before calling
setFetchSize(). But both docs say the return value is "implementation-defined." The implementation-defined value is
thenumber of rows when the current hint is 0.
Then, I'd like to propose the following behavior. Is this OK?
* The default value of defaultRowFetchSize is 100.
* When setFetchSize() is not called, or setFetchSize(0) was called
getFetchSize() returns 100.
The actual number of rows fetched is 100.
* When setFetchSize() was called with a non-zero argument value
getFetchSize() returns that value.
The actual number of rows fetched is that value.
It's unfortunate that the fetch size works only when autocommit is off, but the above change will mitigate the risk of
badimpression that newcomers from other DBMSs may have on PostgreSQL.
Should I submit a patch, or is there someone who wants to do it?
Regards
Takayuki Tsunakawa
