Thread: OUT parameter
Hi, Is there any suggestion against using OUT parameter for local calculation such as using a local variable? CREATE OR REPLACE FUNCTION foo(a IN int, b1 OUT int, b2 OUT int) AS $$ BEGIN FOR (...) LOOP b1 = (...); b2 = (...); END LOOP; END; $$ LANGUAGE PLPGSQL; or for some reasons (performance or whatever other details of implementation), would it be preferable to use local variable and to initialize the OUT parameters at the end? CREATE OR REPLACE FUNCTION foo(a IN int, b1 OUT int, b2 OUT int) AS $$ V_b1 int; V_b2 int; BEGIN FOR (...) LOOP V_b1 = (...); V_b2 = (...); END LOOP; b1 = V_b1; b2 = V_b2; END; $$ LANGUAGE PLPGSQL; Thanks, -- Daniel CAUNE Ubisoft Online Technology (514) 4090 2040 ext. 5418
Daniel Caune wrote: > Is there any suggestion against using OUT parameter for local > calculation such as using a local variable? > > CREATE OR REPLACE FUNCTION foo(a IN int, > b1 OUT int, > b2 OUT int) > AS $$ > BEGIN > FOR (...) LOOP > b1 = (...); > b2 = (...); > END LOOP; > END; > $$ LANGUAGE PLPGSQL; I'd say there's no problem with this, PROVIDED you can ensure you'll never abort before completing the computation. It'snot a good idea to modify out parameters partway; programmers (myself included) have this nasty habit of assuming, rightlyor wrongly, that a failed function call won't have destroyed the parameters. If you can't ensure you'll always complete, use locals. -Owen
> Daniel Caune wrote: >> Is there any suggestion against using OUT parameter for local >> calculation such as using a local variable? In plpgsql (at least in the current implementation) an OUT parameter is pretty much just a local variable, and so there's no efficiency argument against using it as a temporary. Whether you consider this good style is a matter of opinion. "Owen Jacobson" <ojacobson@osl.com> writes: > I'd say there's no problem with this, PROVIDED you can ensure you'll > never abort before completing the computation. Not really an issue in Postgres: we do not support pass-by-reference parameters and are unlikely to start doing so. There isn't any way that you can affect locals of a calling procedure before you return. regards, tom lane
Tom Lane wrote: > "Owen Jacobson" <ojacobson@osl.com> writes: > > I'd say there's no problem with this, PROVIDED you can ensure you'll > > never abort before completing the computation. > > Not really an issue in Postgres: we do not support pass-by-reference > parameters and are unlikely to start doing so. There isn't any way > that you can affect locals of a calling procedure before you return. Then I've misunderstood the semantics of OUT and more importantly INOUT parameters. Thanks for the correction; I'm readingDaniel Caune's notes on the docs now. -Owen
> > "Owen Jacobson" <ojacobson@osl.com> writes: > > > I'd say there's no problem with this, PROVIDED you can ensure you'll > > > never abort before completing the computation. > > > > Not really an issue in Postgres: we do not support pass-by-reference > > parameters and are unlikely to start doing so. There isn't any way > > that you can affect locals of a calling procedure before you return. > > Then I've misunderstood the semantics of OUT and more importantly INOUT > parameters. Thanks for the correction; I'm reading Daniel Caune's notes > on the docs now. > > -Owen Funny! I started that thread on OUT parameter; that's a kind of circle... :-) -- Daniel CAUNE Ubisoft Online Technology (514) 4090 2040 ext. 5418