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.
