From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Couldn't we mark enum_in() as immutable? |
Date: | 2021-09-28 15:04:20 |
Message-ID: | 2838468.1632841460@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Darafei Komяpa Praliaskouski | 2021-09-28 15:13:07 | Re: Couldn't we mark enum_in() as immutable? |
Previous Message | Robert Haas | 2021-09-28 14:59:27 | Re: when the startup process doesn't (logging startup delays) |