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.
