Re: COnsidering a move away from Postgres

Sven Willenberger <sven(at)dmv(dot)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