On Mon, 1 Aug 2005, Tom Lane wrote:
> Chris Mungall <cjm@fruitfly.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
>
