Re: CALL versus procedures with output-only arguments

On 02.06.21 02:04, Tom Lane wrote:
> I wrote:
>> It's possible that we could revert proargtypes and still accommodate
>> the spec's definition for ALTER/DROP ROUTINE/PROCEDURE. I'm imagining
>> some rules along the line of:
>> 1. If arg list contains any parameter modes, then it must be PG
>> syntax, so interpret it according to our traditional rules.
>> 2. Otherwise, try to match the given arg types against *both*
>> proargtypes and proallargtypes. If we get multiple matches,
>> complain that the command is ambiguous. (In the case of DROP
>> PROCEDURE, it's probably OK to consider only proallargtypes.)
>
> Hmm, actually we could make step 2 a shade tighter: if a candidate
> routine is a function, match against proargtypes. If it's a procedure,
> match against coalesce(proallargtypes, proargtypes). If we find
> multiple matches, raise ambiguity error.
>
> The cases where you get the error could be resolved by either
> using traditional PG syntax, or (in most cases) by saying
> FUNCTION or PROCEDURE instead of ROUTINE.

I'm ok with this proposal.