Re: binary patch problems

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

In response to

Responses

Browse pgsql-jdbc by date

  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