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

From Andrew Dunstan
Subject Re: Couldn't we mark enum_in() as immutable?
Date
Msg-id 56d43091-2f7b-4278-25bc-d10c27c66c33@dunslane.net
Whole thread Raw
In response to Couldn't we mark enum_in() as immutable?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Couldn't we mark enum_in() as immutable?
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Trap errors from streaming child in pg_basebackup to exit early
Next
From:
Date:
Subject: RE: (LOCK TABLE options) “ONLY” and “NOWAIT” are not yet implemented