Re: [18] Policy on IMMUTABLE functions and Unicode updates

On Tue, Jul 16, 2024 at 1:16 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Joe Conway <mail(at)joeconway(dot)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.
>
>
I'd teach pg_upgrade to inspect the post-upgraded catalog of is-use
dependencies and report on any of these it finds and remind the DBA that
this latent issue may exist in their system.

I agree the core behaviors of the system would remain unchanged and both
modes would be handled identically. Though requiring superuser or a
predefined role membership to actually use a "static" mode function in an
index or generated expression would be an interesting option to consider.

David J.