Re: CALL versus procedures with output-only arguments

On 03.06.21 22:21, Tom Lane wrote:
> Once you do, you'll possibly notice that PG's rules for which combinations
> of signatures are allowed are different from the spec's. I believe that
> we're largely more generous than the spec, but there are a few cases where
> this proposal isn't. An example is that (AFAICT) the spec allows having
> both
> create procedure divide(x int, y int, OUT q int) ...
> create procedure divide(x int, y int, OUT q int, OUT r int) ...
> which I want to reject because they have the same input parameters.
> This is perhaps annoying. But seeing that the spec won't allow you to
> also have divide() procedures for other datatypes, I'm having a hard
> time feeling that this is losing on the overloading-flexibility front.

I'm okay with disallowing this. In my experience, overloading of
procedures is done even more rarely than of functions, so this probably
won't affect anything in practice.

(I'm by no means suggesting this, but I could imagine a catalog
representation that allows this but still checks that you can't have
multiple candidates that differ only by the type of an OUT parameters.
Say with some kind of bitmap or boolean array that indicates where the
OUT parameters are. Then you can only have one candidate with a given
number of arguments, but the above could be allowed. Again, I'm not
suggesting this, but it's a possibility in theory.)