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

Hello

The core of problems is in standard that doesn't know RETURN NEXT
statement and knows only RETURN TABLE statement - so PL/pgPSM or SQL
doesn't have problem. I am not sure about PL/pgSQL, but I thing so
using TABLE attribs as OUT variables is maybe too simple solution -
there isn't any progress to current state, and where OUT variables are
typically source of mistakes.

Maybe we can use some well defined implicit record, maybe NEW (or
RESULT, ROW_RESULT, ROW, TABLE_ROW, ...) like trigger - some like

create or replace function foo(i int) returns table(a int, b int) as $$
begin for j in 1..i loop   new.a := j; new.b := j+1;   return next new;  -- maybe only RETURN NEXT??? end loop;
end;
$$ language plpgsql

Regards
Pavel Stehule

2008/7/18 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.
>
> 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?
>
> 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.
>
> 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?
>
> For the archives, here is the patch as I currently have it (with the
> no-plpgsql-variables behavior).  But unless I hear a good argument
> to the contrary, I'm going to change that part before committing.
>
>                        regards, tom lane
>
>