| From: | Vaibhav Dalvi <vaibhav(dot)dalvi(at)enterprisedb(dot)com> |
|---|---|
| To: | jian(dot)universality(at)gmail(dot)com |
| Cc: | hackers(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: finish TODOs in to_json_is_immutable, to_jsonb_is_immutable also add tests on it |
| Date: | 2026-01-13 11:12:15 |
| Message-ID: | CA+vB=AELb=QjnpJRJC=m_uz=PGuRNgDJjazBvLbmOWuCgUqHQA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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);
+ }
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?
Best regards,
Vaibhav Dalvi
EnterpriseDB
On Thu, Jan 8, 2026 at 12:35 PM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
> hi.
>
> rebase due to conflict in
>
> https://git.postgresql.org/cgit/postgresql.git/commit/?id=ba75f717526cbaa9000b546aac456e43d03aaf53
>
>
> --
> jian
> https://www.enterprisedb.com/
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Jones | 2026-01-13 11:16:08 | Re: ALTER TABLE: warn when actions do not recurse to partitions |
| Previous Message | Frits Hoogland | 2026-01-13 10:59:39 | Re: static tracepoints in pgstat_report_wait_start/end |