Re: BUG #2108: Function with OUT parameters not recognized, - Mailing list pgsql-bugs

From Tony S
Subject Re: BUG #2108: Function with OUT parameters not recognized,
Date
Msg-id 439DA2ED.7010403@vectorsalad.com
Whole thread Raw
In response to BUG #2108: Function with OUT parameters not recognized, using plpgsql  ("Tony" <tony@vectorsalad.com>)
List pgsql-bugs
Alvaro Herrera wrote:
> Stallone wrote:
>
> Please keep replies on the list.
>
>
>>What you have done is run a SELECT which evaluates the function
>>f_multiparam() passing it two parameters, and then takes the result and
>>puts it INTO a local parameter.  This is not the same.  An OUT parameter
>>is actually passed to the function and is part of the function
>>specification, in this case it is defined as the third parameter.  It's
>>like a placeholder within the definition of the function itself, and it
>>should show up on the list of parameters for that function.  You can, in
>>fact, have many OUT parameters in one function.  This is an advantage of
>>out parameters over just a plain function with a single RETURN element.
>>
>>At least this is how it has always worked for me.
>
>
> Has always worked where?  In Postgres?  It's strange that you mention
> "always" because OUT parameters are new in Postgres 8.1.  Behavior in
> other database systems is not directly applicable to Postgres.
>
> Keep in mind that in Postgres we don't have host variables, which is
> what is needed to make OUT params work the way you are assuming they do.
> This could be improved in the future but currently that's the way it is.
>

I have seriously mistaken the nature of IN/OUT parameters in Postgres.

This misunderstanding all leaked over from Oracle and is not applicable
at all here.  Maybe this might make a good bullet point to add in Sec
36.11 "Porting from Oracle PL/SQL".  I will post a note separately there.

pgsql-bugs by date:

Previous
From: "Jim Dew"
Date:
Subject: BUG #2112: query kills db thread
Next
From: "Michał Szeląg"
Date:
Subject: BUG #2109: NULL=NULL is false