Re: http://www.postgresql.org/docs/8.0/static/xfunc-sql.html

Nigel Horne <njh(at)bandsman(dot)co(dot)uk> writes:
> It strikes me that there are two problems with this approach:

> 1) It stores the return values in the database, that seems a waste
> 2) It's slightly more complicated in that I have to delete the
> return values from the previous call before inserting the return
> values from this call, making it even more complex and slow.

You've misunderstood this completely. We are not storing anything
essential in the table, we're just using its rowtype to describe the
function's composite-type result.

Personally I would have written the example using a composite type
to make this more clear:

CREATE TYPE test_func_type AS (id int, name text);

CREATE FUNCTION test_func() RETURNS SETOF test_func_type AS $$
SELECT 1, 'me' UNION ALL SELECT 2, 'you'
$$ LANGUAGE sql;

select * from test_func();
id | name
----+------
1 | me
2 | you
(2 rows)

regards, tom lane