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 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
I think it is bug because I expect to have the same
string representation of such number regardless
of prepareThreshold. It may be normal or scientific
notation, but SELECT for known, constant parameters
should give the known output. Now output is inconsistent.
In attachment there is Jython code that on my machine
shows:
jdbc:postgresql://test-baza.heuthesd:5494/isof_test?stringtype=unspecified&prepareThreshold=2
--------------
PostgreSQL 9.4.5 on x86_64-unknown-linux-gnu, compiled by gcc (GCC)
4.4.7 20120313 (Red Hat 4.4.7-16), 64-bit
JDBC driver version is 'PostgreSQL 9.4 JDBC4.2 (build 1204)'; major:
9; minor: 4
testing with query: SELECT 1445006113904::float8
--- 1 ---
column type: float8 (8); java: java.lang.Double; precision: 17; scale: 17
getString(): 1445006113904
--- 2 ---
column type: float8 (8); java: java.lang.Double; precision: 17; scale: 17
getString(): 1445006113904
--- 3 ---
column type: float8 (8); java: java.lang.Double; precision: 17; scale: 17
getString(): 1.445006113904E12
STRING FORMAT CHANGED!!!
--
Regards,
Michał Niklas