Peter Eisentraut <peter.eisentraut@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