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.
>
> Here's my reasoning: "immutable" promises that the function will
> always give the same results for the same inputs. However, one of
> the inputs is the type OID for the desired enum type. It's certainly
> possible that the enum type could be dropped later, and then its type
> OID could be recycled, so that at some future epoch enum_in() might
> give a different result for the "same" type OID. But I cannot think
> of any situation where a stored output value of enum_in() would
> outlive the dropping of the enum type. It certainly couldn't happen
> for a table column of that type, nor would it be safe for a stored
> rule to outlive a type it mentions. So it seems like the results of
> enum_in() are immutable for as long as anybody could care about them,
> and that's good enough.
>
> Moreover, if it's *not* good enough, then our existing practice of
> folding enum literals to OID constants on-sight must be unsafe too.
>
> So it seems like this would be okay, and if we did it it'd eliminate
> some annoying corner cases for query optimization, as seen in the
> referenced thread.
>
> I think that a similar argument could be made about enum_out, although
> maybe I'm missing some interesting case there.
>
> Thoughts?
>
>
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.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com