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: | Raw Message | Whole Thread | 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 |