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
