Re: External search engine, advice

Tom Lane wrote:
> 
> mlw <markw@mohawksoft.com> 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 ||
>             ! IsA(fcinfo->resultinfo, ReturnSetInfo))
>                 <complain>;
> 

OK, that makes sense. I will put that in.


> If you fail to do this, you can fully expect your code to coredump
> a version or two hence.  Right now the only possibility for resultinfo
> is to point at a ReturnSetInfo, but that *will* change.
> 
> > create function ftss_search (varchar)
> >       returns setof integer
> >       as '/usr/local/lib/library.so', 'ftss_search'
> >       language 'c' with (iscachable);
> 
> > The above in an example of how one would register this function in postgres.
> 
> Hmm ... given that ftss refers to external files, is it a good idea to
> mark it cachable?  I'd sort of expect that the values it returns for
> a particular argument could change over time.  Cachable amounts to a
> promise that the results for a given argument will not change over time.

This I don't understand. What is the lifetime of a value that "iscacheable?"
Not using "iscacheable" will force a table scan, but are you saying that when a
result is marked "iscacheable" it lasts the life time of the postgres session? 

From what I've been able to tell, a function's value which has been cached
seems only to last the life of a transaction. For instance:

select * from table where field = fubar ('bla bla') ;

When executed, fubar gets called once. On the next invocation of the same
query, fubar is again called. So I don't think cacheable has any more
persistence than transaction. If this isn't the case, then YIKES!