Pavel Stehule <pavel.steh...@gmail.com> writes:
> so 3. 11. 2018 v 22:47 odesílatel Tom Lane <t...@sss.pgh.pa.us> napsal:
>> So while looking at that ... isn't the behavior for non-writable output
>> parameters basically insane? It certainly fails to accord with the
>> plpgsql documentation, which shows an example that would throw an error:
>>
>> CREATE PROCEDURE triple(INOUT x int)
>> ...
>> CALL triple(5);
>>
>> It's even weirder that you can get away with not supplying a writable
>> target value for an output argument so long as it has a default.
>>
>> I think the behavior here ought to be "if the actual argument is a plpgsql
>> variable, assign the output back to it, otherwise do nothing". That's
>> much closer to the behavior of OUT arguments in other old-school
>> programming languages.
> I don't agree. The constant can be used only for IN parameter. Safe
> languages like Ada does copy result to variable used as INOUT parameter.
> PL/SQL doesn't allow it too.
Well, my main point is that that ISN'T what our current code does, nor
does your patch. The reason I'm complaining is that after I rewrote the
code to use expand_function_arguments, it started rejecting this existing
regression test case:
CREATE PROCEDURE test_proc8c(INOUT a int, INOUT b int, INOUT c int DEFAULT 11)
...
CALL test_proc8c(_a, _b);
I do not think you can argue that that's not broken while simultaneously
claiming that this error check promotes safe coding.
I looked into SQL:2011 to see what it has to say about this. In
10.4 <routine invocation>, syntax rule 9) g) iii) says
For each SQL parameter Pi, 1 (one) ≤ i ≤ SRNP, that is an output SQL
parameter or both an input SQL parameter and an output SQL parameter,
XAi shall be a <target specification>.
The immediately preceding rules make it clear that XAi is the actual
argument corresponding to parameter Pi *after* default-insertion and
named-argument reordering. So our existing behavior here clearly
contradicts the spec: DEFAULT is not a <target specification>.
I couldn't find any really clear statement of what PL/SQL does
in this situation, but the docs I did find say that the actual
argument for an OUT parameter has to be a variable, with no
exceptions mentioned.
In short, I think it's a bug that we allow the above. If you
want to keep the must-be-a-variable error then it should apply in
this case too.
regards, tom lane
