Re: proposal: table functions and plpgsql - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: table functions and plpgsql
Date
Msg-id 162867790805211403u34fcc657nf2311877419ae839@mail.gmail.com
Whole thread Raw
In response to Re: proposal: table functions and plpgsql  ("Merlin Moncure" <mmoncure@gmail.com>)
List pgsql-hackers
2008/5/21 Merlin Moncure <mmoncure@gmail.com>:
> On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <hannu@krosing.net> wrote:
>>> In my proposal I don't create any default variables. Result type is
>>> only virtual - I don't need write it to system directory. I thing it's
>>> better than using some specific predeclared type as RESULTTYPE OR
>>> RESULTSET.
>>
>> How is this different from using OUT params and RETURNS SETOF RECORD ?
>
> *) you reference output variables via rowtype (r.var vs. var)
> *) seems cleaner to separate in/out variables so add/drop function are
> symmetric.
>
> Also,
> What about:
>
> CREATE OR REPLACE FUNCTION foo(m integer)
> RETURNS TABLE (a integer, b integer) AS $$
>  -- DECLARE r foo; -- make alias of r to foo optional
> BEGIN
>  FOR i IN 1..m LOOP
>     foo.a := i; foo.b := i + 1;
> [...]
>


I though about it - but there I specify only one result variable and I
directly specify name of variable to programmer. I thing so type
specification is less limited.


> or
> RETURNS TABLE r(a integer, b integer) AS $$
>

It's not ANSI compatible

Pavel

> merlin
>


pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: proposal: table functions and plpgsql
Next
From: Richard Huxton
Date:
Subject: Re: May Commitfest is done!