Refactor our checks for valid function and aggregate signatures.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 17 Mar 2020 23:36:41 +0000 (19:36 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 17 Mar 2020 23:36:41 +0000 (19:36 -0400)
commite6c178b5b73ac1fb822829e6d9b99e3fc1129c21
treecc458fdcb6761971a6c5f6ce1cfd86ac27edfe9f
parentdbbb55385cf5eb75837eb3eb7ca1f14e2beb5a63
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
src/backend/catalog/pg_aggregate.c
src/backend/catalog/pg_proc.c
src/backend/parser/parse_coerce.c
src/include/parser/parse_coerce.h
src/test/regress/expected/plpgsql.out
src/test/regress/expected/polymorphism.out
src/test/regress/expected/rangefuncs.out
src/test/regress/expected/rangetypes.out