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.