Joe Conway <m...@joeconway.com> writes: > So you are proposing we add STATIC to VOLATILE/STABLE/IMMUTABLE (in the > third position before IMMUTABLE), give it IMMUTABLE semantics, mark > builtin functions that deserve it, and document with suitable caution > statements?
What is the point of that, exactly? I'll agree that the user documentation could use some improvement in how it describes the volatility levels, but I do not see how it will reduce anybody's confusion to invent multiple aliases for what's effectively the same volatility level. Nor do I see a use-case for actually having multiple versions of "immutable". Once you've decided you can put something into an index, quibbling over just how immutable it is doesn't really change anything. To put this another way: the existing volatility levels were basically reverse-engineered from the ways that the planner could meaningfully treat a function: it's dangerous, it is safe enough to use in an index condition (which changes the number of times the query will evaluate it), or it's safe to constant-fold in advance of execution. Unless there's a fourth planner behavior that's worth having, we don't need a fourth level. Possibly you could argue that "safe to put in an index" is a different level from "safe to constant-fold", but I don't really agree with that. regards, tom lane