Re: External search engine, advice

Tom Lane wrote:
> 
> mlw <markw@mohawksoft.com> 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.
> 
> As far as optimizing indexscans goes, the correct intermediate concept
> would be something like "result is fixed within any one scan", not any
> one transaction.  You wouldn't really want to find that
> 
>         begin;
>         select * from foo where x = functhatreadsbar();
>         update bar ...;
>         select * from foo where x = functhatreadsbar();
>         end;
> 
> does not give you the desired results.

OK, what is one to do?

There is an obvious need to use functions which return a single value, and
which can be assumed "frozen' for the life of a query or transaction, but would
absolutely break if they could never change after that. This distinction from
"iscachable" is vitally important to people coding functions for Postgres. I
know a lot of what I have written for postgres would break if the desired
meaning of "iscachable" were to be applied.