В качестве общей точки зрения SQL / Path будет более кратким методом запроса структуры данных JSONB. Он будет компилироваться до традиционных методов запросов JSONB. Это делает его синтаксическим анализатором, предоставляя стандартный синтаксис.
Имхо, этот стандартный синтаксис значительно лучше и дает место для будущих оптимизаций, однако любой запрос в JSON может быть выполнен с операторами PostgreSQL, с которыми вы связаны, просто он не всегда хорош.
Узнать, содержит ли этот массив {"foo":2}
, просто.
WITH t(jsonb) AS ( VALUES ('[{"foo":2, "qux":42},{"bar":2},{"baz":4}]'::jsonb) )
SELECT *
FROM t
WHERE jsonb @> '[{"foo":2}]';
Однако значительно сложнее получить значение qux
с учетом вышеизложенного.
WITH t(jsonb) AS ( VALUES ('[{"foo":2, "qux":42},{"bar":2},{"baz":4}]'::jsonb) )
SELECT e->'qux'
FROM t
CROSS JOIN LATERAL jsonb_array_elements(jsonb) AS a(e)
WHERE t.jsonb @> '[{"foo":2}]'
AND e @> '{"foo":2}';
Но это не конец света. Это действительно хороший синтаксис SQL. Это просто не JavaScript. С JSON PATH вы сможете что-то сделать,
SELECT t.json _ '$.[@.foo == 2].qux'
FROM t
WHERE t.json _ '$.[@.foo == 2]';
Где _
- это какой-то оператор JSONPATH. Кроме того, вы всегда можете создать фактическую хранимую процедуру JavaScript на сервере и запустить ее с помощью узла. Это очень просто с pl/v8.