Re: CALL versus procedures with output-only arguments

I wrote:
>> I think we ought to fix this so that OUT-only arguments are ignored
>> when calling from SQL not plpgsql.

Here's a draft patch for that. The docs probably need some more
fiddling, but I think the code is in good shape. (I'm unsure about
the JDBC compatibility issue, and would appreciate someone else
testing that.)

> I'm working on a patch to make it act that way. I've got some issues
> yet to fix with named arguments (which seem rather undertested BTW,
> since the patch is passing check-world even though I know it will
> crash instantly on cases with CALL+named-args+out-only-args).

After I'd finished fixing that, I realized that HEAD is really pretty
broken for the case. For example

regression=# CREATE PROCEDURE test_proc10(IN a int, OUT b int, IN c int)
regression-# LANGUAGE plpgsql
regression-# AS $$
regression$# BEGIN
regression$# RAISE NOTICE 'a: %, b: %, c: %', a, b, c;
regression$# b := a - c;
regression$# END;
regression$# $$;
CREATE PROCEDURE
regression=# DO $$
regression$# DECLARE _a int; _b int; _c int;
regression$# BEGIN
regression$# _a := 10; _b := 30; _c := 7;
regression$# CALL test_proc10(a => _a, b => _b, c => _c);
regression$# RAISE NOTICE '_a: %, _b: %, _c: %', _a, _b, _c;
regression$# END$$;
ERROR: procedure test_proc10(a => integer, b => integer, c => integer) does not exist
LINE 1: CALL test_proc10(a => _a, b => _b, c => _c)
^
HINT: No procedure matches the given name and argument types. You might need to add explicit type casts.
QUERY: CALL test_proc10(a => _a, b => _b, c => _c)
CONTEXT: PL/pgSQL function inline_code_block line 5 at CALL

So even if you object to what I'm trying to do here, there is
work to be done.

regards, tom lane