Tom Lane wrote: > > 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. > > 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. ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
