BUG #16919: Unexpected precision loss in NUMERIC type during text cast, math operations

The following bug has been logged on the website:

Bug reference: 16919
Logged by: Levi Aul
Email address: levi(at)leviaul(dot)com
PostgreSQL version: 13.2
Operating system: Ubuntu 20.04.2 (x86_64), Linux kernel 5.4.0
Description:

Simple operations on NUMERIC, supposedly an arbitrary-precision type, are
having unexpected results for me:

SELECT '12345678901234567890123456789012345678901234567890'::numeric;
-- expected 12345678901234567890123456789012345678901234567890
-- got 12345678901234567890123456789012345678900000000000

SELECT (('123456789012345678901234567890'::numeric) *
('100000000000000000000'::numeric)) + ('12345678901234567890'::numeric);
-- expected 12345678901234567890123456789012345678901234567890
-- got 12345678901234567890123456789012345678900000000000

Correct results can be attained by replacing NUMERIC in the above with
pgmp's mpz type.

Also, this precision loss doesn't occur with the internal _numeric
array-member type:

SELECT
'{12345678901234567890123456789012345678901234567890}'::numeric[];
-- expected {12345678901234567890123456789012345678901234567890}
-- got {12345678901234567890123456789012345678901234567890}

I've verified with debug_print_parse that nothing strange is going on with
implicit casts overriding the defaults; the native function numeric_in is
being called here. (And even if it weren't, having an overridden (text TO
numeric) cast wouldn't also be affecting the math-op result above, as it
operates upon apparently-lossless inputs while still achieving a lossy
result.)