Re: CALL versus procedures with output-only arguments

On 31.05.21 22:25, Tom Lane wrote:
> I wrote:
>> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
>>> I don't see that.
>
>> It's under CREATE PROCEDURE. 11.60 <SQL-invoked routine> SR 20 says
>
> Oh... just noticed something else relevant to this discussion: SR 13
> in the same section saith
>
> 13) If R is an SQL-invoked function, then no <SQL parameter declaration>
> in NPL shall contain a <parameter mode>.
>
> In other words, the spec does not have OUT or INOUT parameters for
> functions. So, again, their notion of what is sufficient to identify
> a routine is based on a very different model than what we are using.

Yeah, I figured that was known, but maybe it is good to point it out in
this thread.

The OUT and INOUT parameters for functions and how they affect
signatures was "invented here" for PostgreSQL.

The OUT and INOUT parameters for procedures is something that exists in
the standard and other implementations.

Unfortunately, these two things are not consistent.

So now when we add OUT parameters for procedures in PostgreSQL, we are
forced to make a choice: Do we choose consistency with precedent A or
precedent B? That's the point we disagree on, and I'm not sure how to
resolve it.

Another dimension to this question of what things are consistent with is
how you reference versus how you invoke these things.

If you have a function f1(IN xt, OUT yt), you reference it as f1(xt) and
you invoke it as SELECT f1(xv).

If you have a procedure p1(IN xt, OUT yt), you invoke it as CALL
p1(something, something). So in my mind, it would also make sense to
reference it as p1(something, something).

So while I understand the argument of

- Function signatures should work consistently with procedure signatures.

I find the arguments of

- Procedure signatures should match the SQL standard, and
- Signature for invoking should match signature for calling.

a more appealing combination.

Does that summarize the issue correctly?