Peter Eisentraut <peter.eisentr...@enterprisedb.com> writes: > On 24.05.21 02:01, Tom Lane wrote: >>> I think we ought to fix this so that OUT-only arguments are ignored >>> when calling from SQL not plpgsql.
> I don't understand why you want to change this. The argument resolution > of CALL is specified in the SQL standard; we shouldn't just make up our > own system. I don't really see how you can argue that the existing behavior is more spec-compliant than what I'm suggesting. What I read in the spec (SQL:2021 10.4 <routine invocation> SR 9) h) iii) 1)) is 1) If Pi is an output SQL parameter, then XAi shall be a <target specification>. (where <target specification> more or less reduces to "variable"). Now, sure, that's what we've got in plpgsql, and I'm not proposing to change that. But in plain SQL, as of HEAD, you are supposed to write NULL, or a random literal, or indeed anything at all *except* a variable. How is that more standard-compliant than not writing anything? Also, one could argue that the behavior I'm suggesting is completely spec-compliant if one assumes that the OUT parameters have some sort of default, allowing them to be omitted from the call. More generally, there are enough deviations from spec in what we do to perform ambiguous-call resolution that it seems rather silly to hang your hat on this particular point. Now as against that, we are giving up a whole lot of consistency. As of HEAD: * The rules for what is a conflict of signatures are different for functions and procedures. * The rules for how to identify a target routine in ALTER, DROP, etc are different for functions and procedures. That's especially nasty in ALTER/DROP ROUTINE, where we don't have a syntax cue as to whether or not to ignore OUT parameters. * The rules for how to call functions and procedures with OUT parameters from SQL are different. * Client code that looks at pg_proc.proargtypes is almost certainly going to be broken. I don't like any of those side-effects, and I don't want to pay those prices for what seems to me to be a bogus claim of improved spec compliance. regards, tom lane