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 <[email protected]> wrote: > On Tue, Jan 13, 2026 at 7:12 PM Vaibhav Dalvi > <[email protected]> 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 >
