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

From Tom Lane
Subject CALL versus procedures with output-only arguments
Date
Msg-id 3742981.1621533210@sss.pgh.pa.us
Whole thread Raw
Responses Re: CALL versus procedures with output-only arguments
Re: CALL versus procedures with output-only arguments
List pgsql-hackers
I'm not too happy with this:

regression=# create procedure p1(out x int) language plpgsql
regression-# as 'begin x := 42; end';
CREATE PROCEDURE

regression=# call p1();
ERROR:  procedure p1() does not exist
LINE 1: call p1();
             ^
HINT:  No procedure matches the given name and argument types. You might need to add explicit type casts.

regression=# call p1(null);
 x
----
 42
(1 row)

I can see that that makes some sense within plpgsql, where the CALL
ought to provide a plpgsql variable for each OUT argument.  But it
seems moderately insane for calls from SQL.  It certainly fails
to match the documentation [1], which says fairly explicitly that
the argument list items match the *input* arguments of the procedure,
and further notes that plpgsql handles output arguments differently.

I think we ought to fix this so that OUT-only arguments are ignored
when calling from SQL not plpgsql.  This is less than simple, since
the parser doesn't actually have any context that would let it know
which one we're doing, but I think we could hack that up somehow.
(The RawParseMode mechanism seems like one way we could pass the
info, and there are probably others.)

Alternatively, if we're going to stick with this behavior, we have
to change the docs to explain it.  Either way it seems like an
open item for v14.  (For those who've forgotten, OUT-only procedure
arguments are a new thing in v14.)

            regards, tom lane

[1] https://www.postgresql.org/docs/devel/sql-call.html



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Race condition in recovery?
Next
From: Bruce Momjian
Date:
Subject: Re: Query about time zone patterns in to_char