On 9/28/21 11:04 AM, Tom Lane wrote: > Andrew Dunstan <and...@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
