Fix some minor error-checking oversights in ParseFuncOrColumn().
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 16 Jun 2018 18:10:17 +0000 (14:10 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 16 Jun 2018 18:11:14 +0000 (14:11 -0400)
commit0dcf68e5a1f1c600bdf29b47cab30a62301a7af1
tree127bccdbc95b71fab225358f0201eba2a47d8060
parent15378c1a15390a2b4c315f19f1644af46c7e3a15
Fix some minor error-checking oversights in ParseFuncOrColumn().

Recent additions to ParseFuncOrColumn to make it reject non-procedure
functions in CALL were neither adequate nor documented.  Reorganize
the code to ensure uniform results for all the cases that should be
rejected.  Also, use ERRCODE_WRONG_OBJECT_TYPE for this case as well
as the converse case of a procedure in a non-CALL context.  The
original coding used ERRCODE_UNDEFINED_FUNCTION which seems wrong,
and is certainly inconsistent with the adjacent wrong-kind-of-routine
errors.

This reorganization also causes the checks for aggregate decoration with
a non-aggregate function to be made in the FUNCDETAIL_COERCION case;
that they were not is a long-standing oversight.

Discussion: https://postgr.es/m/14497.1529089235@sss.pgh.pa.us
src/backend/parser/parse_func.c
src/test/regress/expected/create_procedure.out