Re: binary patch problems - Mailing list pgsql-jdbc

From Bodor Andras
Subject Re: binary patch problems
Date
Msg-id 4E775CA7.3080303@gmail.com
Whole thread Raw
In response to Re: binary patch problems  (Bodor Andras <bodri.mh3@gmail.com>)
List pgsql-jdbc
Self correction: I did not read the documentation
carefully enough. prepareThreshold = 1 should be used.
Negative values are changed to 0 by the driver. But
it should be mentioned somewhere, that 0 switches it
off completely.

Bodor Andras wrote:
> 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 by date:

Previous
From: Guillaume
Date:
Subject: jdbc and automagic casting
Next
From: boris
Date:
Subject: Re: jdbc and automagic casting