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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Couldn't we mark enum_in() as immutable?
Дата
Msg-id 2838468.1632841460@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Couldn't we mark enum_in() as immutable?  (Andrew Dunstan <andrew@dunslane.net>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: when the startup process doesn't (logging startup delays)
Следующее
От: Darafei "Komяpa" Praliaskouski
Дата:
Сообщение: Re: Couldn't we mark enum_in() as immutable?