W dniu 16.10.2015 o 12:15, Vladimir Sitnikov pisze:
>> I changed those codes to use System.currentTimeMillis().
>
>> why JDBC or database backend changes format of returned value
>> after my use count reaches prepareThreshold parameter.
>
> We JDBC driver cannot ensure stable string representation of
> non-string data. That might change as database improves. That might
> change as JDBC driver improves.
I hope things improves :-)
I do not complain that this changed, just wanted to know
why this changed.
>> 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.
>
>
>> I do not observe this with JDBC drivers in version 9.3,
>
> The thing is older versions did not manage to use server-prepared
> statements for prepareStatement(); .call(); Recently pgjdbc learned
> to use server-prepared statement even in case application does not
> care to reuse PreparedStatements:
>
http://stackoverflow.com/questions/32297503/whats-the-life-span-of-a-postgresql-server-side-prepared-statement/32300222#32300222
Thanks
>
for explanation.
That is what I was looking for.
I looked at change log and did not find this.
>> then I simplified code that now is even more portable (as we work
>> with other databases)
>
> Can you share the code?
My statement "more portable" was joke :-)
Idea to get number of milliseconds from database was terrible,
and it was simply mistake.
We love PostgreSQL, but for such thing Java and
System.currentTimeMillis() is much better.
This code was used to profile some piece of code.
It was very bad idea and ugly code, but it was the only
query I was able to find that show toString() format change.
And such format change was very mysterious for me.
Thanks for your help!
--
Regards,
Michał Niklas