Re: Calling SQL functions that return sets

On Mon, 1 Aug 2005, Tom Lane wrote:

> Chris Mungall <cjm(at)fruitfly(dot)org> writes:
> > What are the reasons for deprecating the use of the function in the
> > SELECT clause?
>
> The semantics of having more than one set-returning function in the
> target list are, um, poorly thought out. However, we haven't removed
> the feature because (as you note) there are things you can't do any
> other way.

Would you recommend I press ahead and define views that make use of setof
function calling in the select clause? I would need to be reasonably
confident that if this is more strongly deprecated in future versions I
can at least recode my views (using some as-yet-to-be-defined function
definition and calling mechanism) and preserve their existing semantics.

Is there any roadmap for how this will be handled in future versions?
Understandably, this may not be a high priority.

I'm sure you and the other developers have already thought a lot about
this, but for what it's worth I'd like to pich in a vote for taking a
prolog-esque approach here. In prolog, everything is a relation. A
function taking two arguments is really just a 3-ary relation over
(arg1,arg2,result). Thus functions that produce more than one value (eg
sqrt) don't require any extensions to the relational model.

I amn't the slightest bit familair with the Pg internals, and there may be
some very good reasons that make this impractical.

Coming back to earth, I have a more specific question which follows on
from my initial question. If I have a function 'foo' which takes one
argument and returns a setof some table or composite type, it seems I am
unable to call the function from the select clause.

SELECT foo(1,2);
ERROR: set-valued function called in context that cannot accept a set

SELECT mycol(foo(1,2));
ERROR: set-valued function called in context that cannot accept a set

It looks like I may be stuck anyway....

Cheers
Chris

> regards, tom lane
>