Re: COnsidering a move away from Postgres

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: COnsidering a move away from Postgres
Дата
Msg-id 21454.1120164219@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: COnsidering a move away from Postgres  (Sven Willenberger <sven@dmv.com>)
Список pgsql-general
Sven Willenberger <sven@dmv.com> writes:
> As far as hard coding the OUT datatypes, if I understand the docs
> correctly you can even:
> CREATE FUNCTION foo(IN i int, OUT x anyelement, OUT y anyelement, OUT z
> anyelement) AS ...

That exact example would not work --- anyelement/anyarray is all about
deducing output parameter types from input parameter types.  So you need
at least one anyelement or anyarray input parameter.  Here's a pretty
stupid example:

regression=# create function sum_n_prod (x anyelement, y anyelement,
regression(# OUT sum anyelement, OUT prod anyelement) as $$
regression$# begin
regression$#   sum := x + y;
regression$#   prod := x * y;
regression$# end$$ language plpgsql;
CREATE FUNCTION

This will work on any data type that has + and * operators.  You can't
tell very easily in psql, but the first of these examples returns two
integers and the second returns two numeric columns:

regression=# select * from sum_n_prod(33,44);
 sum | prod
-----+------
  77 | 1452
(1 row)

regression=# select * from sum_n_prod(33.4,44.7);
 sum  |  prod
------+---------
 78.1 | 1492.98
(1 row)


I'm not entirely clear on exactly what problem Jason is concerned about,
but I don't think anyelement/anyarray will help him much.  I do however
think that the out-parameter facility mostly fixes the specific
complaint of having to invent composite types just to return more than
one column.

            regards, tom lane

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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: optimizer not optimizing
Следующее
От: Tom Lane
Дата:
Сообщение: Re: COnsidering a move away from Postgres