PostGIS has a very similar thing: ST_Transform is marked as immutable but does depend on contents of spatial_ref_sys table. Although it is shipped with extension and almost never changes incompatibly, there are scenarios where it breaks: dump/restore + index or generated column can fail the import if data gets fed into the immutable function before the contents of spatial_ref_sys is restored. I'd love this issue to be addressed at the core level as benefits of having it as immutable outweigh even this unfortunate issue.
Andrew Dunstan <andrew@dunslane.net> writes: > On 9/27/21 5:54 PM, Tom Lane wrote: >> Currently enum_in() is marked as stable, on the reasonable grounds >> that it depends on system catalog contents. However, after the >> discussion at [1] I'm wondering why it wouldn't be perfectly safe, >> and useful, to mark it as immutable.
> The value returned depends on the label values in pg_enum, so if someone > decided to rename a label that would affect it, no? Same for enum_out.
Hm. I'd thought about this to the extent of considering that if we rename label A to B, then stored values of "A" would now print as "B", and const-folding "A" earlier would track that which seems OK. But you're right that then introducing a new definition of "A" (via ADD or RENAME) would make things messy.
>> Moreover, if it's *not* good enough, then our existing practice of >> folding enum literals to OID constants on-sight must be unsafe too.
I'm still a little troubled by this angle. However, we've gotten away with far worse instability for datetime literals, so maybe it's not a problem in practice.
