On 25.05.21 22:21, Tom Lane wrote:
> Yeah, the odd behavior of CALL is where I started from, but now I think
> the main problem is with the signature (ie, allowing procedures with
> signatures that differ only in OUT parameter positions). If we got
> rid of that choice then it'd be possible to document that you should
> only ever write NULL for OUT-parameter positions, because the type
> of such an argument would never be significant for disambiguation.
AFAICT, your patch does not main the property that
CREATE PROCEDURE p1(OUT int, OUT int)
corresponds to
DROP PROCEDURE p1(int, int)
which would be bad.
I'm not opposed to reverting the feature if we can't find a good
solution in a hurry. The main value is of this feature is for
migrations, so I want to be sure that whatever we settle on doesn't back
us into a corner with respect to that.
We could perhaps also just disable the SQL-level calling until a better
solution arises. AFAICT, things work okay in PL/pgSQL, because OUT
parameters are tied to a typed target there.
