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/pgdo...RATION-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
>
>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> Maybe we can use some well defined implicit record, maybe NEW (or
> RESULT, ROW_RESULT, ROW, TABLE_ROW, ...) like trigger - some like

That sounds like exactly the sort of kluge-solution that I didn't
want to get involved with ...

Anyway, the core feature is in, and we still have several months
before 8.4 feature freeze to debate how plpgsql ought to interact
with it.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

2008/7/18 Tom Lane <tgl@sss.pgh.pa.us>:
> "Pavel Stehule" <pavel.stehule@gmail.com> writes:
>> Maybe we can use some well defined implicit record, maybe NEW (or
>> RESULT, ROW_RESULT, ROW, TABLE_ROW, ...) like trigger - some like
>
> That sounds like exactly the sort of kluge-solution that I didn't
> want to get involved with ...
>
> Anyway, the core feature is in, and we still have several months
> before 8.4 feature freeze to debate how plpgsql ought to interact
> with it.
>

I agree.
Regards

p.s.

other solution - using referenced types

declare foorec fcename%ROWTYPE -- allows only current fce name
fooscalar fcename.col%TYPE

regards
Pavel Stehule

and many thanks for commit this patch


> regards, tom lane
>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers