Re: More inaccurate results from numeric pow()

Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> In fact it's possible to predict exactly how large we need to allow
> "val" to become, since the final result is computed using exp_var(),
> which accepts inputs up to 6000, so the result weight "val" can be up
> to around log10(exp(6000)) ~= 2606 before the final result causes an
> overflow.

> The obvious fix would be to modify the clamping limits. I think a
> better answer though is to replace the clamping code with an overflow
> test, immediately throwing an error if "val" is outside the allowed
> range, per the attached patch.

I don't much care for the hardwired magic number here, especially since
exp_var() does not have its limit expressed as "6000" but as
"NUMERIC_MAX_RESULT_SCALE * 3".  I think you should rephrase the limit
to use that expression, and also add something like this in exp_var():
val = numericvar_to_double_no_overflow(&x);
/* Guard against overflow */
+    /* If you change this limit, see also power_var()'s limit */if (Abs(val) >= NUMERIC_MAX_RESULT_SCALE * 3)
ereport(ERROR,           (errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),             errmsg("value overflows numeric
format")));

Seems like a reasonable idea otherwise.
        regards, tom lane