Re: binary patch problems
От | Bodor Andras |
---|---|
Тема | Re: binary patch problems |
Дата | |
Msg-id | 4E7753F7.9090903@gmail.com обсуждение исходный текст |
Ответ на | Re: binary patch problems (Bodor Andras <bodri.mh3@gmail.com>) |
Ответы |
Re: binary patch problems
Re: binary patch problems |
Список | pgsql-jdbc |
You are right. But then it is a bug in either the code, or the documentation. It says: prepareThreshold = int Determine the number of PreparedStatement executions required before switching over to use server side prepared statements. I think, if zero executions are required, then the driver should use prepared statement immediately. Both permanently disabling and immediately enabling is a legitimate need of the users, it should be clearly documented, how to do them. Anyway, setting prepareThreshold = -1 will do what I meant. But it is more logical to me, that 0 means zero and -1 means infinity (even better: Integer.MAX_VALUE). For the ForceBinaryTransfers I vote for dropping it, as it adds unnecessary complications (and new bugs) to the code. Andras >> Why don't you set prepareThreshold to 0 for your test cases? >> In this case parameter passing starts immediately for the >> prepared statement, and ForceBinaryTransfers can be dropped. >> Andras >> >AbstractJdbc2Statement: > public boolean isUseServerPrepare() { > return (preparedQuery != null && m_prepareThreshold != 0 && >m_useCount + 1 >= m_prepareThreshold); > } > >If I read the above correctly then prepareThreshold of 0 disables >prepared statements. > >-Mikko
В списке pgsql-jdbc по дате отправления: