Hi, On 2018-10-05 11:54:59 -0400, Tom Lane wrote: > Andres Freund <[email protected]> writes: > > [ let's use strfromd ] > > So I'm having second thoughts about this, based on the fact that > strfromd() in't strictly a glibc-ism but is defined in an ISO/IEC > standard. That means that we can expect to see it start showing up > on other platforms (though a quick search did not find any evidence > that it has yet). And that means that we'd better consider > quality-of-implementation issues. We know that glibc's version is > fractionally faster than using sprintf with "%.*g", but what are > the odds that that will be true universally? I don't have a warm > feeling about it, given that strfromd's API isn't a very good impedance > match to what we really need. > > I really think that what we ought to do is apply the float[48]out hack > I showed in <[email protected]> and call it good, at least > till such time as somebody wants to propose a full-on reimplementation of > float output. I don't want to buy back into having platform dependencies > in this area after having just expended a lot of sweat to get rid of them.
I'm not convinced. Because of some hypothetical platform that may introduce strfromd() in a broken/slower manner, but where sprintf() is correct, we should not do the minimal work to alleviate an actual performance bottleneck in a trivial manner on linux? Our most widely used platform? If we find a platform where it's borked, we could just add a small hack into their platform template file. Greetings, Andres Freund
