pgsql: Handle numeric overflow in numeric_minmax_multi_ops

Handle numeric overflow in numeric_minmax_multi_ops

When calculating the distance between numeric values, the code could
overflow in two ways. A subtraction of two finite values may still
overflow, or the result may not fit into float8.

The distances don't need to be perfectly accurate, although it may make
the index less efficient. And for most minmax-multi opclasses it works
like that, but for numeric the functions may error-out. That prevents
summarization, either when creating an index or later during vacuum.

Fix by using numeric_sub_safe() and numeric_float8_no_overflow(), and
returning infinity when either of those fails. The older releases need
to use numeric_sub_opt_error(), but the principle is the same.

Also, handle NaN values the same as for float4/float8. When both values
are NaN, return distance 0. When one value is NaN, return infinity.

While at it, free the detoasted copies of arguments, and the calculated
numeric distance. For small values it does not matter, but for extreme
numeric values it may make a difference.

Reported by Kirill Reshke, with a patch fixing the issue. Various
improvements and backpatching by me.

Backpatch to 14, where minmax-multi indexes were introduced.

Author: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Author: Tomas Vondra <tomas(at)vondra(dot)me>
Reviewed-by: shihao zhong <zhong950419(at)gmail(dot)com>
Backpatch-through: 14
Discussion: https://postgr.es/m/CALdSSPgBvXz-VSF0p-5k%3D_uFfN38cWrERmm_AC4K67N6MWQhmg%40mail.gmail.com

Branch
------
REL_17_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/9ab2a624ebe92431d19a92367e8a99dccfc5e10a

Modified Files
--------------
src/backend/access/brin/brin_minmax_multi.c | 39 ++++++++++++++++++++++++-----
src/test/regress/expected/brin_multi.out | 10 ++++++++
src/test/regress/sql/brin_multi.sql | 14 +++++++++++
3 files changed, 57 insertions(+), 6 deletions(-)