Hi so 3. 11. 2018 v 22:47 odesÃlatel Tom Lane <t...@sss.pgh.pa.us> napsal:
> I wrote: > > I'm going to go see about converting this to just call > > expand_function_arguments and then drop all the special-case code. > > 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. https://stackoverflow.com/questions/9977229/oracle-pls-00363-expression-cannot-be-used-as-an-assignment-target The implemented limit can be good detection of passing parameters in bad order. Regards Pavel > > regards, tom lane >
