| From: | Bodor Andras <bodri(dot)mh3(at)gmail(dot)com> |
|---|---|
| To: | pgsql-jdbc(at)postgresql(dot)org |
| Subject: | Re: binary patch problems |
| Date: | 2011-09-19 14:38:47 |
| Message-ID: | 4E7753F7.9090903@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume | 2011-09-19 14:39:38 | jdbc and automagic casting |
| Previous Message | Mikko Tiihonen | 2011-09-19 13:53:38 | Re: binary patch problems |