Re: PostgresSQL 10 | Driver 42.2.5 | Float Conversion Issue

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Andreas Joseph Krogh <andreas(at)visena(dot)com>
Cc: "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 16:46:17
Message-ID: CAKFQuwbbYTc63HeEBPXcDzPU28Do4z+y9ZEwQKVFwCnbPP1FaQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

On Mon, Oct 19, 2020 at 11:46 PM Andreas Joseph Krogh <andreas(at)visena(dot)com>
wrote:

> På tirsdag 20. oktober 2020 kl. 08:43:55, skrev Thangavel, Parameswaran <
> Parameswaran(dot)Thangavel(at)rsa(dot)com>:
>
> When I run the select statement, I am getting different data…
>
> I suggest you use the native "psql"-client and chech the results from that
> first.
>

Specifically this behavior can be readily observed using the following
query:

SELECT '1.234567+e06'::float4::numeric;

As I mentioned in the original -bugs report for this issue [1] I don't know
whether the above is correct or not. What I can say is the regression
demonstrated in the example Java program could be readily avoided by not
passing around floating point values when the database storage is numeric.

Since the confusing behavior can be shown using just PostgreSQL the
original bug report suffices as a place to get the final explanation as to
what is going on here.

David J.

[1]
https://www.postgresql.org/message-id/flat/CH2PR19MB3798B24BCC34D3F9949F629C83000%40CH2PR19MB3798.namprd19.prod.outlook.com

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Andreas Joseph Krogh 2020-10-20 16:53:17 Re: PostgresSQL 10 | Driver 42.2.5 | Float Conversion Issue
Previous Message Andreas Joseph Krogh 2020-10-20 06:46:40 RE: PostgresSQL 10 | Driver 42.2.5 | Float Conversion Issue