>On 9 October 2015 11:44 Michał Niklas wrote:
>
> > W dniu 16.10.2015 o 12:15, Vladimir Sitnikov pisze:
> > [...]
> >> If I set prepareThreshold=5 then I get float in normal notation
> >> up to 5th try, and then from 6th try I get this value in
> >> scientific notation.
> >
> > Well, that is thanks to usage of server-prepared statement. In that
> > mode, pgjdbc can use binary format of data transfer. It does use
> > binary mode for types it knows as it is more efficient to transfer
> > and parse.
>
> OK, but I think string representation of such float should
> not change during program life.
I understand that it can be confusing at first, but correctly functioning applications would not care.
> I tested JDBC driver with much simpler query:
> SELECT 1445006113904::float8
> so there is known, constant number.
>
> Up to prepareThreshold I got: 1445006113904,
> then I got: 1.445006113904E12
What you see is difference between PostgreSQL server side doing the
formatting vs the java Double.toString function doing the formatting.
Up to the threshold the call is really SELECT 1445006113904::float8::text
After that the jdbc driver requests the exact float8 bits (which is faster and takes up less space).
Because you request a String from result set instead of double the jdbc driver has to format the string.
If you want consistent String representation you need to do for example:
Double.toString(resultSet.getDouble())
An alternative is to request binary transfers from the first query, but this jdbc driver feature is
supposed to be more of a debug feature, because it slows down queries due to needing an extra
round-trip for each query.
If we consider this a bug then we just need to replicate the server side float to text formatter code
inside the jdbc driver instead of using Java built in formatters.
-Mikko