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
