Re: Couldn't we mark enum_in() as immutable?

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.

On Tue, Sep 28, 2021 at 6:04 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Andrew Dunstan <andrew(at)dunslane(dot)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.
>
> regards, tom lane
>
>
>