Kyotaro Horiguchi <horikyota.ntt@xxxxxxxxx> 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
