Re: PostgresSQL 10 | Driver 42.2.5 | Float Conversion Issue

Vladimir Sitnikov <sitnikov.vladimir@gmail.com> writes:
> Tom>Note the waffling immediately after that, though.
> I assume PostgreSQL switched to Ryu around release 12 or so.

> Should float4_numeric switch to Ryu as well?
> I guess it would be both faster and more precise.

Ryu or not, it'd have the issue of sometimes presenting digits the user
wasn't expecting, if the user is under the illusion that float is exact.
I'd rather document "this is always rounded to N digits" than have to
explain the cases where Ryu doesn't produce an "exact" result.
You don't have to look far for examples, eg

# select 1234567890::float4;
    float4
---------------
 1.2345679e+09
(1 row)

# select '0.98765456'::float4;
   float4
------------
 0.98765457
(1 row)

You have to keep in mind that what Ryu does (or claims to do anyway)
is produce the shortest decimal sequence that float4in will map back
to the same float4 bit pattern.  While this does often produce
"unsurprising" results, that is not guaranteed once you're past
six digits.

Now, I suppose there is something to be said for ensuring that
float::numeric and float::text::numeric produce the same answers,
which we'd get if we made float4_numeric and float8_numeric use
Ryu instead of the current method.  But that's not going to
change the fact that the OP is doing it wrong by expecting
exact results from what he's doing.

[ digs in archives... ]  The original thread about the Ryu patch [1]
considered this, and ultimately decided not to on the grounds
that float4_numeric is marked immutable and therefore we should
not change its behavior.  I'm not sure if that argument is
really irrefutable, but it's something to think about.

In any case, the JDBC list is not where to be complaining if you
want a server behavior change.

            regards, tom lane

[1] https://www.postgresql.org/message-id/flat/87r2el1bx6.fsf%40news-spur.riddles.org.uk