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?
regards, tom lane
[1] https://www.postgresql.org/message-id/9a51090e-e075-4f2f-e3a6-55ed4359a357%40kimmet.dk