Re: TABLE-function patch vs plpgsql - Mailing list pgsql-hackers

On 7/18/08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I've been working on the TABLE-function patch, and I am coming to the
>  conclusion that it's really a bad idea for plpgsql to not associate
>  variables with output columns --- that is, I think we should make
>  RETURNS TABLE columns semantically just the same as OUT parameters.
>  Here are some reasons:
>
>  1. It's ludicrous to argue that "standards compliance" requires the
>  behavior-as-submitted.  plpgsql is not specified by the SQL standard.

Yes, but it would be a good feature addition to plpgsql.
Currently there is no way to suppress the local variable
creation.  The proposed behaviour would give that possibility.

>  2. Not having the parameter names available means that you don't have
>  access to their types either, which is a big problem for polymorphic
>  functions.  Read the last couple paragraphs of section 38.3.1:
>  http://developer.postgresql.org/pgdocs/postgres/plpgsql-declarations.html#PLPGSQL-DECLARATION-ALIASES
>  as well as the following 38.3.2.  How would you do those things with
>  a polymorphic TABLE column?

This does not make sense as Postgres does not support
polymorphic table columns...

For polymorphic function arguments user should use OUT parameters.

I think thats the point - it should not be just syntactic sugar for
OUT parameters, let it be different.

>  3. Not treating the parameters as assignable variables makes RETURN NEXT
>  nearly worthless in a TABLE function.  Since they're not assignable,
>  you can't use the parameterless form of RETURN NEXT (which'd return
>  the current values of the variables).  The only alternative available
>  is to return a record or row variable; but there's no convenient way
>  to declare such a variable, since after all the whole point here is
>  that the function's output rowtype is anonymous.
>
>  4. It's a whole lot easier to explain things if we can just say that
>  OUT parameters and TABLE parameters work alike.  This is especially
>  true when they actually *are* alike for all the other available PLs.

What other PLs do create local variables for OUT parameters?

>  If we insist on the current definition then we are eventually going to
>  need to kluge up some solutions to #2 and #3, which seems like make-work
>  to me when we already have smooth solutions to these problems for
>  OUT parameters.
>
>  Comments?

I would prefer - no local vars, no polymorphism and funcname%rowtype.

Some functions are better written with OUT parameters but some
with record variable for return rows.  The new behaviour would
allow picking best coding style for a function.

-- 
marko