| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: SQL/JSON: JSON_TRANSFORM (SQL standard, subclause 6.44) |
| Date: | 2026-06-20 21:30:58 |
| Message-ID: | CAN4CZFPN=887T0njqw+bOHUiO6ion6rR=b1+Ecx+gAaCuL89Wg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello
I do not have access to the standard, so I can only look at the patch
based on the Oracle documentation - my questions are based on that.
1. Isn't rename supposed to default to `REPLACE ON EXISTING`? [1]
SELECT JSON_TRANSFORM('{"a":1,"b":2}'::jsonb, RENAME '$.a' = 'b'); --
returns {"b":2}, shouldn't be {"b":1}?
2. I'm also not sure about the insert behavior [2], currently the
above query doesn't do anything:
SELECT JSON_TRANSFORM('{"x":1}'::jsonb, INSERT '$.a.b' = '9');
The Oracle documentation says that the default behavior is `INSERT ON
MISSING`, but also that "path expression must target either a field of
an object or an array position (otherwise, an error is raised).". The
correct behavior for this should be either inserting the record, or
raising an error. Probably the latter.
3. Unfortunately I wasn't able to find anything in the documentation
about the case where a wildcard doesn't match anything, such as:
SELECT JSON_TRANSFORM('{}', REMOVE '$.*' ERROR ON MISSING);
SELECT JSON_TRANSFORM('{}', REPLACE '$.*' = '9' ERROR ON MISSING);
Currently these report an error, which might be correct, but seems
somewhat strange to me, so I wanted to mention it to confirm the
behavior.
[1]: https://docs.oracle.com/en/database/oracle/oracle-database/26/adjsn/json_transform-operator-rename.html
[2]: https://docs.oracle.com/en/database/oracle/oracle-database/26/adjsn/json_transform-operator-insert.html
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-06-20 21:46:19 | Re: Fix HAVING-to-WHERE pushdown with mismatched operator families |
| Previous Message | Daniil Davydov | 2026-06-20 18:52:06 | Re: BUG with accessing to temporary tables of other sessions still exists |