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

Andrew Dunstan  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