From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Oleg Bartunov <obartunov(at)postgrespro(dot)ru>, Teodor Sigaev <teodor(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Jsonpath ** vs lax mode |
Date: | 2021-01-20 17:13:05 |
Message-ID: | CAPpHfdtS-nNidT=EqZbAYOPcnNOWh_sd6skVdu2CAQUGdvpT8Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi!
We have a bug report which says that jsonpath ** operator behaves strangely
in the lax mode [1].
Naturally, the result of this query looks counter-intuitive.
# select jsonb_path_query_array('[{"a": 1, "b": [{"a": 2}]}]', 'lax
$.**.a');
jsonb_path_query_array
------------------------
[1, 1, 2, 2]
(1 row)
But actually, everything works as designed. ** operator reports both
objects and wrapping arrays, while object key accessor automatically
unwraps arrays.
# select x, jsonb_path_query_array(x, '$.a') from jsonb_path_query('[{"a":
1, "b": [{"a": 2}]}]', 'lax $.**') x;
x | jsonb_path_query_array
-----------------------------+------------------------
[{"a": 1, "b": [{"a": 2}]}] | [1]
{"a": 1, "b": [{"a": 2}]} | [1]
1 | []
[{"a": 2}] | [2]
{"a": 2} | [2]
2 | []
(6 rows)
At first sight, we may just say that lax mode just sucks and
counter-intuitive results are expected. But at the second sight, the lax
mode is used by default and current behavior may look too surprising.
My proposal is to make everything after the ** operator use strict mode
(patch attached). I think this shouldn't be backpatched, just applied to
the v14. Other suggestions?
Links
1.
https://www.postgresql.org/message-id/16828-2b0229babfad2d8c%40postgresql.org
------
Regards,
Alexander Korotkov
Attachment | Content-Type | Size |
---|---|---|
jsonpath_double_star_strict_mode.patch | application/octet-stream | 5.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-01-20 17:19:29 | Re: strange error reporting |
Previous Message | Robert Haas | 2021-01-20 17:08:41 | strange error reporting |