On Tue, Jul 16, 2024 at 1:16 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
> 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. > > 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.
