On 02/26/2018 01:29 PM, Tom Lane wrote: > I think there's probably a bigger chance of complaints that > "casting 1.1::float8 to numeric now produces some weird, > incorrectly-rounded result" than that we make anyone happier.
Arguably, though, that's a moment that can be used to explain exactly what the correctly-rounded value of 1.1::float8 is and why, and then people both know something new and understand more precisely what's happening to their data, and can apply round() to it in exactly the places they want, if they want. In contrast, the current fact that 1.1::float8 looks like 1.1 when cast to numeric puts a superficial smile on people's faces, while they haven't really been asked how they feel about losing five, six, or thirty-eight bits of precision when casting one data type into another of supposedly greater precision and back. I think the typical assumption is that, sure, you may lose precision if you cast to a *less* precise type, but the other direction's assumed value-preserving. I can see the concern about changing behavior for code that may exist already. I would never have thought of making the behavior of a cast sensitive to extra_float_digits (in fact, I hadn't known about extra_float_digits; it's described in the "locale and formatting" section, which I never dreamed of consulting for a cast between internal value representations; am I weird in that?). I wonder if an alternative to making a cast that can't be immutable, because it looks at a GUC, could be to offer a choice of cast functions: if you need the other behavior, create a schema, do a CREATE CAST in it, and put it on your search path ahead of pg_catalog. Kind of ugly, but that can happen dealing with kind of ugly situations. -Chap
