Обсуждение: 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