Andres Freund <and...@anarazel.de> writes: > It seems the general "use strfromd if available" approach is generally > useful, even if we need to serialize the precision.
Agreed. > Putting it into an > inline appears to be helpful, avoids some of the otherwise precision > related branches. Do you have any feelings about which header to put > the code in? I used common/string.h so far. I do not think it should be in a header, for two reasons: (1) The need to use sprintf for portability means that we need very tight constraints on the precision spec *and* the buffer size *and* the format type (%f pretty much destroys certainty about how long the output string is). So this isn't going to be general purpose code. I think just writing it into float[48]out is sufficient. (2) It's already the case that most code trying to emit floats ought to go through float[48]out, in order to have standardized treatment of Inf and NaN. Providing some other API in a common header would just create a temptation to break that policy. Now, if we did write our own float output code then we would standardize Inf/NaN outputs inside that, and both of these issues would go away ... but I think what we'd do is provide something strfromd-like as an alternate API for that code, so we still won't need a wrapper. And anyway it doesn't sound like either of us care to jump that hurdle right now. regards, tom lane