Refactor our checks for valid function and aggregate signatures.
pg_proc.c and pg_aggregate.c had near-duplicate copies of the logic
to decide whether a function or aggregate's signature is legal.
This seems like a bad thing even without the problem that the
upcoming "anycompatible" patch would roughly double the complexity
of that logic. Hence, refactor so that the rules are localized
in new subroutines supplied by parse_coerce.c. (One could quibble
about just where to add that code, but putting it beside
enforce_generic_type_consistency seems not totally unreasonable.)
The fact that the rules are about to change would mandate some
changes in the wording of the associated error messages in any case.
I ended up spelling things out in a fairly literal fashion in the
errdetail messages, eg "A result of type anyelement requires at
least one input of type anyelement, anyarray, anynonarray, anyenum,
or anyrange." Perhaps this is overkill, but once there's more than
one subgroup of polymorphic types, people might get confused by
more-abstract messages.
Discussion: https://postgr.es/m/24137.1584139352@sss.pgh.pa.us
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/e6c178b5b73ac1fb822829e6d9b99e3fc1129c21
Modified Files
--------------
src/backend/catalog/pg_aggregate.c | 53 ++++++-------
src/backend/catalog/pg_proc.c | 115 +++++++++++------------------
src/backend/parser/parse_coerce.c | 71 ++++++++++++++++++
src/include/parser/parse_coerce.h | 7 ++
src/test/regress/expected/plpgsql.out | 2 +-
src/test/regress/expected/polymorphism.out | 38 +++++-----
src/test/regress/expected/rangefuncs.out | 2 +-
src/test/regress/expected/rangetypes.out | 10 +--
8 files changed, 176 insertions(+), 122 deletions(-)