Skip site navigation (1) Skip section navigation (2)

Re: proposal: table functions and plpgsql

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
Cc: "Hannu Krosing" <hannu(at)krosing(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: table functions and plpgsql
Date: 2008-05-21 21:03:53
Message-ID: 162867790805211403u34fcc657nf2311877419ae839@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2008/5/21 Merlin Moncure <mmoncure(at)gmail(dot)com>:
> On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <hannu(at)krosing(dot)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
>

In response to

pgsql-hackers by date

Next:From: Richard HuxtonDate: 2008-05-21 21:04:13
Subject: Re: May Commitfest is done!
Previous:From: Pavel StehuleDate: 2008-05-21 21:01:10
Subject: Re: proposal: table functions and plpgsql

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group