Re: CALL versus procedures with output-only arguments

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.

An interesting point here is that if you did, say,
create procedure p1(IN x int, IN y float8, OUT z int)
create procedure p1(IN x int, OUT y float8, IN z int)
these would be allowed by my preferred catalog design (since
proargtypes would be different), but their proallargtypes are
the same so you could not drop one using SQL-spec syntax.
You'd be forced into using traditional PG syntax. Since the
spec would disallow the case anyway, I don't see an argument
that this is a problem for spec compliance.

I'm not very sure offhand how thoroughly this approach
covers the expectations of the spec. There may be combinations
of procedure/function signatures that the spec thinks should
be allowed but would be ambiguous according to these rules for
DROP ROUTINE. But I believe that any such cases would be
pretty corner-ish, and we could get away with saying "too bad".

regards, tom lane