Re: Couldn't we mark enum_in() as immutable? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Couldn't we mark enum_in() as immutable?
Date
Msg-id 2838468.1632841460@sss.pgh.pa.us
Whole thread Raw
In response to Re: Couldn't we mark enum_in() as immutable?  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Couldn't we mark enum_in() as immutable?  (Darafei "Komяpa" Praliaskouski <me@komzpa.net>)
Re: Couldn't we mark enum_in() as immutable?  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: when the startup process doesn't (logging startup delays)
Next
From: Darafei "Komяpa" Praliaskouski
Date:
Subject: Re: Couldn't we mark enum_in() as immutable?