<div>Is there any chance that you will reflect this in the documentation?</div><div>Thank you.</div><div> </div><div>11.07.2022, 18:49, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>:</div><blockquote><p>PG Bug reporting form <<a href="mailto:noreply(at)postgresql(dot)org" rel="noopener noreferrer">noreply(at)postgresql(dot)org</a>> writes:</p><blockquote> When a certain number (p, s) with a fractional part (specific examples -<br /> 1.11 and 69.96) is multiplied by a power (10, N), the resulting value is<br /> distorted.<br /> However, if the power(10, N) is manually converted to an integer, the<br /> resulting value is correct.<br /> It looks like there is some kind of problem with the automatic type<br /> conversion of the power() function.</blockquote><p><br />Your query is invoking the float8 variant of power(), which is<br />necessarily of limited precision. If I change "w.degree::integer"<br />to "w.degree::numeric", then it invokes the numeric variant of<br />power(), and I get correctly rounded results (much more slowly<br />unfortunately :-(). So I don't see any bug here.<br /><br />It might be surprising that the parser prefers float8 over numeric<br />when the given function arguments don't exactly match either one.<br />But that's a very ancient decision that we're not going to change.<br />There is support for it in the SQL standard, which directs<br />implementations to prefer inexact numeric types over exact ones<br />when they have to make a choice.<br /><br /> regards, tom lane</p></blockquote>