Peter Eisentraut <peter.eisentraut@enterprisedb.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