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.