Re: CALL versus procedures with output-only arguments - Mailing list pgsql-hackers

From Tom Lane
Subject Re: CALL versus procedures with output-only arguments
Date
Msg-id 1211811.1621956026@sss.pgh.pa.us
Whole thread Raw
In response to Re: CALL versus procedures with output-only arguments  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: CALL versus procedures with output-only arguments
Re: CALL versus procedures with output-only arguments
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Replace run-time error check with assertion
Next
From: Alvaro Herrera
Date:
Subject: Re: Test of a partition with an incomplete detach has a timing issue