> Tom Lane wrote:
> >
> > begin;
> > select * from foo where x = functhatreadsbar();
I thought that the per statement way to do it with a non cacheable function was:
select * from foo where x = (select functhatreadsbar());
??
Andreas
PS: an iscacheable function without
mlw <[EMAIL PROTECTED]> writes:
> Am I out in left field here? Does anyone see this as a problem? I guess there
> should be three states to the lifetime of a functions return value?
There has been some talk of that, but nailing down exactly what the
semantics ought to be still needs more thought.
mlw <[EMAIL PROTECTED]> writes:
>> Hmm ... given that ftss refers to external files, is it a good idea to
>> mark it cachable?
> This I don't understand. What is the lifetime of a value that "iscacheable?"
Forever. cachable says it's OK to reduce "func(constant)" to "constant"
on sight. Right
mlw <[EMAIL PROTECTED]> writes:
> The above is an example of how to write a function that returns multiple
> results.
One suggestion: you must check not only that fcinfo->resultinfo isn't
NULL, but that it points at the sort of node you're expecting. Say
if (fcinfo->resultinfo == NULL |
mlw <[EMAIL PROTECTED]> writes:
> If I do:
> create temp table fubar as select ftss_results() as songid;
> select * from cdsongs where songid = fubar.songid;
> That works, but that is slow and a lot of people have emotional difficulties
> with using temporary tables.
If you don't like temp tables
mlw <[EMAIL PROTECTED]> writes:
> freedb=# select * from cdsongs where songid = ftss_results() ;
> ERROR: Set-valued function called in context that cannot accept a set
'=' is a scalar operation. Try
select * from cdsongs where songid IN (select ftss_results());
regard
> Well, I kind of have that already. I can return a set, but I can't use it in a
> join.
>
> freedb=# select ftss_search('all { pink floyd money }') ;
> ftss_search
> -
> 120
> (1 row)
>
> freedb=# select * from cdsongs where songid = ftss_results() ;
> ERROR: Set-valued
