On 9/28/21 11:04 AM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.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.
>
>
Yeah, I suspect it's not.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
