Re: HISTORY updated, 7.3 branded

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: HISTORY updated, 7.3 branded
Дата
Msg-id 3D7664B0.8020603@joeconway.com
обсуждение исходный текст
Ответ на Re: HISTORY updated, 7.3 branded  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: HISTORY updated, 7.3 branded  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: HISTORY updated, 7.3 branded
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: HISTORY updated, 7.3 branded