• Tom Lane's avatar
    Refactor our checks for valid function and aggregate signatures. · e6c178b5
    Tom Lane authored
    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
    e6c178b5
rangefuncs.out 61.7 KB