Re: CALL versus procedures with output-only arguments

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> On 03.06.21 22:21, Tom Lane wrote:
>> 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.

> (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.)

We could certainly do something like that in a green field. But one
of the reasons I'm unhappy about the current design is that I'm convinced
that altering the definition of pg_proc.proargtypes will break client-side
code that's looking at the catalogs. I don't think we get to monkey with
such fundamental bits of the catalog data without a really good reason.
Allowing different OUT parameters for the same IN parameters doesn't seem
to me to qualify, given that there are other reasons why that's dubious.

regards, tom lane