Jsonpath ** vs lax mode

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Jsonpath ** vs lax mode
Дата
Msg-id CAPpHfdtS-nNidT=EqZbAYOPcnNOWh_sd6skVdu2CAQUGdvpT8Q@mail.gmail.com
обсуждение исходный текст
Ответы Re: Jsonpath ** vs lax mode  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: Jsonpath ** vs lax mode  (Thomas Kellerer <shammat@gmx.net>)
Список 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

------
Regards,
Alexander Korotkov
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: strange error reporting
Следующее
От: Tom Lane
Дата:
Сообщение: Re: strange error reporting