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