Re: CALL versus procedures with output-only arguments

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.