Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> Even given this, premising users keeping the volatility marks in line
> with the actual behavior of their corresponding functions, it might be
> benetifical to prohibit changes to the volatility category while it's
> being used for indices.
Are you going to prohibit changes to the function's behavior, which is
what actually matters? And if so, how will you enforce that? Even if
we had an understanding of the function body --- which we generally
don't for PL functions --- determining that would be equivalent to
solving the halting problem. "Refuse *all* updates to the pg_proc
entry" might sound like a solution; but it is not, because the
function might call another one whose behavior could get changed.
Even granting that we had a useful way to enforce such a restriction,
figuring out whether to apply it would be subject to race conditions;
maybe somebody else is in process of creating an index using the
function that's being altered.
In the end, adding such restrictions would just give a false sense
of security, because there would always be gaps in whatever we did.
As you quote from the documentation, volatility markings are a promise
by the user to the system, not vice versa. If you break your promise,
you get to keep both pieces of whatever trouble ensues.
regards, tom lane
