Joe Conway <mail@joeconway.com> writes:
>> create or replace function test2() returns setof foot as 'select * from
>> foot order by 1 asc' language 'sql';
>> create or replace function test(setof foot) returns foot as 'select
>> $1.f1, $1.f2' language 'sql';
Uh, where exactly are you storing the information that the function
accepts a setof argument?
(We probably should be rejecting the above syntax at the moment, but
I suspect the parser just fails to notice the setof marker.)
A more serious objection is that this doesn't really address the
fundamental issue, namely that you can't drive a SRF from the results of
a query, except indirectly via single-purpose function definitions (like
test2() in your example).
I'm leaning more and more to the thought that we should reconsider the
Berkeley approach.
Another line of thought is to consider the possibilities of subselects
in the target list. For example,
SELECT ..., (SELECT ... FROM mysrf(a, b)) FROM foo WHERE ...;
I believe it's already the case that foo.a and foo.b can be transmitted
as arguments to mysrf() with this notation. The restriction is that the
sub-select can only return a single value (one row, one column) to the
outer query. It doesn't seem too outlandish to allow multiple columns
to be pulled up into the outer SELECT's result list given the above
syntax. I'm less sure about allowing multiple rows though. Any
thoughts?
regards, tom lane