From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: HISTORY updated, 7.3 branded |
Date: | 2002-09-04 19:53:20 |
Message-ID: | 3D7664B0.8020603@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> C functions have always been able to return sets too; you don't honestly
> think that a SQL function can do something a C function can't, do you?
The original dblink is an example.
>
> There are really two independent improvements here: one is the ability
> for plpgsql functions to return sets, and the other is a group of
> improvements that make it easier to use a function-returning-set,
> independently of what language it's written in.
>
As an example, although you *could* return a composite type before, it
was almost useless, because what you actually got returned to you was a
pointer:
test=# create function get_foo() returns setof foo as 'select * from
foo' language sql;
CREATE
test=# select get_foo();
get_foo
-----------
137867648
137867648
137867648
(3 rows)
In order to get the individual columns, you had to do:
test=# select f1(get_foo()), f2(get_foo()), f3(get_foo());
f1 | f2 | f3
----+----+-----
1 | 1 | abc
1 | 2 | def
2 | 1 | ghi
(3 rows)
Pretty ugly, but it did work.
What about this:
Functions returning multiple rows and/or multiple columns are
now much easier to use than before. You can call such a
"table function" in the SELECT FROM clause, treating its output
like a table. Also, plpgsql functions can now return sets.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-09-04 20:04:27 | Re: HISTORY updated, 7.3 branded |
Previous Message | Tom Lane | 2002-09-04 19:13:18 | Re: HISTORY updated, 7.3 branded |