Ken Tanzer <ken.tanzer@gmail.com> writes:
> I've wondered in the past about Immutable functions, and particularly the
> scope & lifetime of "forever" in "guaranteed to return the same results
> given the same arguments forever." I assume that's "for all users and all
> sessions," but either in theory or in practice is there a limit to how long
> a stale value might persist?
The two issues I can think of offhand are (a) plans that depend on the
assumption of immutability might persist for the life of active sessions;
(b) if you created an index on the result of an immutable function,
changing the function's behavior would likely render the index
inconsistent. (REINDEX would be enough to fix that, though.)
> And, if you were to drop and recreate a
> function with the same name & parameters, would it start fresh at that
> point?
DROP (not CREATE OR REPLACE) would surely get rid of any dependent
values.
> Finally, I'm wondering if there's any legitimate reason for a immutable
> function to call anything stable or volatile, and if not would it make any
> sense to emit a warning when the function is created.
We've been around on that before, and concluded that it's not worth it.
People have in the past used phony-immutable functions to coerce the
optimizer to do what they want --- in fact, that use case is one of the
reasons why we have the inlining restriction. I'm not sure if such
practices are still popular, but somebody who was doing that would not
appreciate nannyism.
regards, tom lane