CALL versus procedures with output-only arguments

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: CALL versus procedures with output-only arguments
Date: 2021-05-20 17:53:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I'm not too happy with this:

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

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);
(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



Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-05-20 18:25:15 Re: Query about time zone patterns in to_char
Previous Message Robert Haas 2021-05-20 17:49:10 Re: Race condition in recovery?