Hi, On 2019-05-20 23:56:33 +0100, Andrew Gierth wrote: > [ To: header pruned ] > > >>>>> "Andres" == Andres Freund <and...@anarazel.de> writes: > > Andres> <para> > Andres> Avoid performing unnecessary rounding of <link > Andres> linkend="datatype-float"><type>REAL</type></link> and > <type>DOUBLE > Andres> PRECISION</type> values (Andrew Gierth) > Andres> </para> > > Andres> <para> > Andres> This dramatically speeds up processing of floating-point > Andres> values but causes additional trailing digits to > Andres> potentially be displayed. Users wishing to have output > Andres> that is rounded to match the previous behavior can set <link > Andres> > linkend="guc-extra-float-digits"><literal>extra_float_digits=0</literal></link>, > Andres> which is no longer the default. > Andres> </para> > Andres> </listitem> > > Andres> Isn't it exactly the *other* way round? *Previously* we'd > Andres> output additional trailing digits. The new algorithm instead > Andres> will instead have *exactly* the required number of digits? > > Yeah, this wording is not right. But your description is also wrong. > > Previously we output values rounded to 6+d or 15+d digits where > d=extra_float_digits, with d=0 being the default. Only clients that > wanted exact results would set that to 3 instead. > > Now we output the minimum digits to get an exact result, which is > usually 8 or 17 digits (sometimes less depending on the value, or 9 for > the relatively rare float4 values that need it) for any > extra_float_digits value > 0. Clients that set d=3 will therefore > usually get one less digit than before, and the value they get will > usually be slightly different (i.e. not the same value that they would > have seen with d=2), but it should give them the same binary value after > going through strtod() or strtof().
Any chance for you to propose a text? Greetings, Andres Freund
