Re: finish TODOs in to_json_is_immutable, to_jsonb_is_immutable also add tests on it

Hi Jian,

Thanks for your detailed explanation. This makes sense to me as well.

Regards,
Vaibhav

On Wed, Jan 21, 2026 at 2:09 PM jian he <jian(dot)universality(at)gmail(dot)com> wrote:

> On Tue, Jan 13, 2026 at 7:12 PM Vaibhav Dalvi
> <vaibhav(dot)dalvi(at)enterprisedb(dot)com> wrote:
> >
> > Hi Jian,
> >
> > Thanks for working on this. The patch looks good, but I have a few
> observations:
> >
> > 1. Index creation fails for range types regardless of the base data type:
> >
> > postgres=# create type range_int as range(subtype=int);
> > CREATE TYPE
> > postgres=# create table range_table(r1 range_int);
> > CREATE TABLE
> > postgres=# create index on range_table(json_array(r1 returning jsonb));
> > ERROR: functions in index expression must be marked IMMUTABLE
> >
> > I believe this is because range_out is a stable function. Consequently,
> the following
> > code snippet in to_jsonb_is_immutable may be redundant, or should simply
> return
> > false without recursing for the sub-type:
> >
> > + else if (att_typtype == TYPTYPE_RANGE)
> > + {
> > + to_jsonb_is_immutable(get_range_subtype(typoid), contain_mutable);
> > + }
> >
>
> yech, your observation is right.
>
> create index on range_table((r1::text));
>
> will fail, because pg_proc.provolatile is 's' for function range_out.
>
> but imagine the function range_out marked as immutable, then we would
> need to recurse to the range's subtype.
> also, it makes the logic more complite: if the type is container type,
> recurse to check its elemental/subtype.
>
> Therefore, I am inclined to leave it unchanged.
>
> > 2. Regarding the function names to_jsonb_is_immutable and
> to_json_is_immutable:
> > since these do not return a boolean value, "is" may no longer be
> appropriate. Perhaps
> > something like to_jsonb_check_mutable would be more accurate?
> >
>
> to_jsonb_is_immutable and to_json_is_immutable are marked as extern, so
> they may
> be used by other extensions. Renaming them would require extension authors
> to
> discover and update to the new symbol names. Adding an additional argument
> makes
> the change immediately visible through a signature mismatch.
>
> so I think we should stick to the current name.
>
> --
> jian
> https://www.enterprisedb.com
>