Re: Ryu floating point output patch - Mailing list pgsql-hackers

From Donald Dong
Subject Re: Ryu floating point output patch
Date
Msg-id EF3D7988-9FD4-4233-BEE6-A86FE678AC52@csumb.edu
Whole thread Raw
In response to Re: Ryu floating point output patch  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Ryu floating point output patch  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
> On Jan 19, 2019, at 5:12 PM, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>
>>>>>> "Donald" == Donald Dong <xdong@csumb.edu> writes:
>
> Donald> I think the previous additional digits behavior still exist
> Donald> in the latest patch. For example:
>
> Donald> =# set extra_float_digits = 0;
> Donald> SET
> Donald> =# select float4in('1.123456789');
> Donald>  float4in
> Donald> ----------
> Donald>   1.12346
> Donald> (1 row)
>
> Donald> =# set extra_float_digits = 1;
> Donald> SET
> Donald> =# select float4in('1.123456789');
> Donald>  float4in
> Donald> -----------
> Donald>  1.1234568
> Donald> (1 row)
>
> Donald> The extra_float_digits is increased by 1, but two digits are
> Donald> added.
>
> That's intentional; this patch takes any value of extra_float_digits
> greater than 0 to mean "generate the shortest precise output".
>
> In practice setting extra_float_digits to 1 is rare to nonexistent;
> almost all users of extra_float_digits set it to either 3 (to get
> precise values), 2 (for historical reasons since we didn't allow more
> than 2 in older versions), or less than 0 (to get rounded output for
> more convenient display when precision is not required).

Makes sense! Thank you for explaining.

I wonder if it's necessary to update the doc accordingly? Such as
https://www.postgresql.org/docs/11/datatype-numeric.html#DATATYPE-FLOAT
and
https://www.postgresql.org/docs/11/runtime-config-client.html
.



pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: Ryu floating point output patch
Next
From: Andrew Gierth
Date:
Subject: Re: Thread-unsafe coding in ecpg