Jsonpath ** vs lax mode

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

Responses

Browse pgsql-hackers by date

  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