Обсуждение: Couldn't we mark enum_in() as immutable?

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.

Here's my reasoning: "immutable" promises that the function will
always give the same results for the same inputs.  However, one of
the inputs is the type OID for the desired enum type.  It's certainly
possible that the enum type could be dropped later, and then its type
OID could be recycled, so that at some future epoch enum_in() might
give a different result for the "same" type OID.  But I cannot think
of any situation where a stored output value of enum_in() would
outlive the dropping of the enum type.  It certainly couldn't happen
for a table column of that type, nor would it be safe for a stored
rule to outlive a type it mentions.  So it seems like the results of
enum_in() are immutable for as long as anybody could care about them,
and that's good enough.

Moreover, if it's *not* good enough, then our existing practice of
folding enum literals to OID constants on-sight must be unsafe too.

So it seems like this would be okay, and if we did it it'd eliminate
some annoying corner cases for query optimization, as seen in the
referenced thread.

I think that a similar argument could be made about enum_out, although
maybe I'm missing some interesting case there.

Thoughts?

            regards, tom lane

[1] https://www.postgresql.org/message-id/9a51090e-e075-4f2f-e3a6-55ed4359a357%40kimmet.dk

> On 27 Sep 2021, at 23:54, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> So it seems like the results of
> enum_in() are immutable for as long as anybody could care about them,
> and that's good enough.

+1. I can't think of a situation where this wouldn't hold.

--
Daniel Gustafsson        https://vmware.com/

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.
>
> Here's my reasoning: "immutable" promises that the function will
> always give the same results for the same inputs.  However, one of
> the inputs is the type OID for the desired enum type.  It's certainly
> possible that the enum type could be dropped later, and then its type
> OID could be recycled, so that at some future epoch enum_in() might
> give a different result for the "same" type OID.  But I cannot think
> of any situation where a stored output value of enum_in() would
> outlive the dropping of the enum type.  It certainly couldn't happen
> for a table column of that type, nor would it be safe for a stored
> rule to outlive a type it mentions.  So it seems like the results of
> enum_in() are immutable for as long as anybody could care about them,
> and that's good enough.
>
> Moreover, if it's *not* good enough, then our existing practice of
> folding enum literals to OID constants on-sight must be unsafe too.
>
> So it seems like this would be okay, and if we did it it'd eliminate
> some annoying corner cases for query optimization, as seen in the
> referenced thread.
>
> I think that a similar argument could be made about enum_out, although
> maybe I'm missing some interesting case there.
>
> Thoughts?
>
>             


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.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

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

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