On 7/16/24 16:16, Tom Lane wrote:
> Joe Conway <mail@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.
Fair enough, but then I think we should change the documentation to not
say "forever".
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com