From: Tom Lane <tgl@sss.pgh.pa.us>
To: su.sinodan@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17546: power() function - value is distorted via automatic
 type cast
In-reply-to: <17546-d71fe78a505f9f7b@postgresql.org>
References: <17546-d71fe78a505f9f7b@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 11 Jul 2022 15:20:21 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1119192.1657554589.1@sss.pgh.pa.us>
Date: Mon, 11 Jul 2022 11:49:49 -0400
Message-ID: <1119193.1657554589@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1119193.1657554589%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> When a certain number (p, s) with a fractional part (specific examples -
> 1.11 and 69.96) is multiplied by a power (10, N), the resulting value is
> distorted.
> However, if the power(10, N) is manually converted to an integer, the
> resulting value is correct.
> It looks like there is some kind of problem with the automatic type
> conversion of the power() function.

Your query is invoking the float8 variant of power(), which is
necessarily of limited precision.  If I change "w.degree::integer"
to "w.degree::numeric", then it invokes the numeric variant of
power(), and I get correctly rounded results (much more slowly
unfortunately :-().  So I don't see any bug here.

It might be surprising that the parser prefers float8 over numeric
when the given function arguments don't exactly match either one.
But that's a very ancient decision that we're not going to change.
There is support for it in the SQL standard, which directs
implementations to prefer inexact numeric types over exact ones
when they have to make a choice.

			regards, tom lane