Re: INOUT parameters in procedures

2018-03-05 19:41 GMT+01:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

>
>
> 2018-03-05 19:38 GMT+01:00 Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)
> com>:
>
>> On 3/5/18 11:00, Pavel Stehule wrote:
>> > I am looking on attached code, and it looks pretty well. Can be really
>> > nice if this code will be part of release 11, because it is very
>> > interesting, important feature feature.
>>
>> Here is an updated patch, rebased on top of several recent changes, also
>> added more documentation and tests in other PLs.
>>
>> > p.s. can be nice, if we allow same trick with calling of OUT variables
>> > functions in plpgsql
>> >
>> > fx(in a, out x, out y) return int -- but requires some special mark
>> >
>> > do $$
>> > declare x int, y int, z int;
>> > begin
>> > z := fx(10, x, y);
>> > raise notice '% ....
>> >
>> > Then migration from Oracle can be really easy and friendly
>>
>> This would require some changes to how routines are looked up, because
>> we currently ignore OUT parameters there. That code does not exist yet.
>> But it's certainly a plausible extension for the future.
>>
>
> sure - this is topic for 12 release. But it can fix more than one issue
> when PL/SQL code is migrated.
>
> note: in this case we should to return one parameter more. Out parameters
> + RETURN expression result.
>

this problem is simple/difficult. the type of function can be detected from
call context - when function is called with assigned out variable(s) (all
OUT variables should be assigned), then the behave should be classical -
and RETURN expression for non void functions should be required. Else, the
OUT variables should not be assigned, and function will be called in
postgresql style - the function returns tuple defined by OUT parameters and
RETURN expression is prohibited. Some hint can be returning type - if it is
not defined, then result is defined just by OUT variables, when it is
defined (and it is not RECORD), then RETURN expression is required. When
RETURNS type is RECORD, then we know nothing and decision should be based
on calling context.

>> --
>> Peter Eisentraut http://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>
>
>