| From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Andreas Joseph Krogh <andreas(at)visena(dot)com>, "Thangavel, Parameswaran" <Parameswaran(dot)Thangavel(at)rsa(dot)com>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
| Subject: | Re: PostgresSQL 10 | Driver 42.2.5 | Float Conversion Issue |
| Date: | 2020-10-20 20:06:47 |
| Message-ID: | CAB=Je-H8NiTt_+roUXzv=UiL6QWG-7QzihMVvpXrwyq8FLuo3w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
Tom>The SQL standard
https://www.postgresql.org/docs/13/datatype-numeric.html#DATATYPE-FLOAT
The documentation says that PostgreSQL implements IEEE Standard 754.
1234567 is exactly representable in IEEE (e.g. see
https://www.exploringbinary.com/floating-point-converter/ ),
so I would expect the database should keep the value intact.
1234567 is exactly representable in both float4 and numeric, so it is
surprising that 1234567::float4::numeric::text yields 1234570 in PG 12.2
----
In case that matters, pgjdbc does send pass extra_float_digits=2 in the
initial packet, then it upgrades to extra_float_digist=3 in case server
version is 9.0+
I did try removing that parameter, and it does not resolve
1234567::float4::numeric::text issue
Vladimir
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-10-20 20:33:06 | Re: PostgresSQL 10 | Driver 42.2.5 | Float Conversion Issue |
| Previous Message | Tom Lane | 2020-10-20 19:53:18 | Re: PostgresSQL 10 | Driver 42.2.5 | Float Conversion Issue |