Re: TABLE-function patch vs plpgsql

On Wed, 2008-07-30 at 07:29 +0200, Pavel Stehule wrote:
> 2008/7/29 Hannu Krosing <hannu(at)krosing(dot)net>:
> > On Thu, 2008-07-17 at 19:13 -0400, Tom Lane 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.
> >
> > I just looked at recent cahnges in pl/python, and found out that RETURNS
> > TABLE is _NOT_ semantically just the same as OUT parameters, at least at
> > API level.
> >
> > Why can't it be ?
> >
> > Why is PROARGMODE_TABLE needed at all ?
>
> because I need to separate classic OUT args from table args.

I read your explanation, and I still don't understand, why can't TABLE
and SETOF RECORD + OUT args be just different spellings of the same
thing.

Is there a scenario, where both are needed in the same function ?

> TABLE function has more clean syntax, then our SRF functions,

True. But why is separation on C API level needed ?

> and it isn't
> related only to SQL/PSM. It works nice together with SQL language.
> Actually TABLE variables are exactly same as OUT variables (in
> plpgsq), that is possible, but I am not sure, if it's best too.

Still I have the same question - What is the difference ?

> I have prototype where is possible declare variables derivated from
> function return type
> create function foo(..) returns table(x int, y int) as $$
> declare result foo%rowtype; resx foo.x%type; ....

I still don't see, why the same thing can't work on

create function foo(OUT x int, OUT y int) returns setof record as $$
declare result foo%rowtype; resx foo.x%type; ...

> all this has to minimalist risk of variables and sql object name collisions.

Are there any cases, where TABLE functions and OUT + returns SETOF
RECORD functions are _called_ differently ?

------------------
Hannu