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

Re: proposal: table functions and plpgsql

From: Hannu Krosing <hannu(at)krosing(dot)net>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: table functions and plpgsql
Date: 2008-05-21 18:14:47
Message-ID: 1211393687.7045.17.camel@huvostro (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 2008-05-21 at 13:31 -0400, Merlin Moncure wrote:
> 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)

As I'm currently working on updating another pl (pl/python), I'd like to
know how will this affect get_call_result_type() defined in funcapi.h.
will there be an extra parameter for record name there ?

> *) seems cleaner to separate in/out variables so add/drop function are
> symmetric.

they are kind of symmetric already :)

´╗┐hannu=# drop function outsetof2py(n integer, OUT i integer, OUT j
integer);
DROP FUNCTION


> 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;
> [...]
> 
> or
> RETURNS TABLE r(a integer, b integer) AS $$

rather "..FUNCTION foo(...) ... RETURNS TABLE r(..." as else it will be
hard to do recursive functions.

> merlin
> 


In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2008-05-21 21:01:10
Subject: Re: proposal: table functions and plpgsql
Previous:From: Tom LaneDate: 2008-05-21 18:07:56
Subject: May Commitfest is done!

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