Robert Haas <robertmhaas@gmail.com> writes:
> I'm also concerned about the behavior here. I noticed it when this
> commit went in, and it seemed concerning to me then, and it still
> does. Nevertheless, I'm not convinced that your proposal is an
> improvement. Suppose we have foo(int, out int) and also foo(int).
> Then, if I understand correctly, under your proposal, foo(4) will call
> the former within plpgsql code, because in that context the OUT
> parameters must be included, and the latter from SQL code, because in
> that context they must be emitted.
No, you misunderstand my proposal. The thing that I most urgently
want to do is to prevent that situation from ever arising, by not
allowing those two procedures to coexist, just as you can't have
two functions with such signatures.
If procedures are required to have distinct signatures when considering
input parameters only, then a fortiori they are distinct when also
considering output parameters. So my proposal cannot make a CALL
that includes output parameters ambiguous if it was not before.
> I don't see any really great choice here, but in some sense your
> proposal seems like the worst of all the options. It does not reverse
> the patch's choice to treat functions and procedures differently, so
> users will still have to deal with that inconsistency.
You're definitely confused, because reversing that choice is *exactly*
what I'm on about. The question of whether SQL-level CALL should act
differently from plpgsql CALL is pretty secondary.
regards, tom lane