Комментарии 28
Обновляем значение объекта по ключу. 25 здесь является числом, но взято в кавычки, потому что присваиваемое значение должно быть jsonbА если я хочу записать 25 как строку?
В коммите в примере:
update test_jsonb_subscript set test_json['a'] = '1' where id = 1;
select * from test_jsonb_subscript;
id | test_json
----+------------------
2 | {"key": "value"}
1 | {"a": 1}
(2 rows)
'"25"'
Ага… т.е. когда надо сделать такое как ниже, то нужно будет и далее кастить?
И если вот это вероятно будет работать и без cast(age as varchar) (из за нативного неявного преобразования между numeric и varchar):
select * from t1 where jf['age'] in (select cast(age as varchar) from t2)то здесь нужно будет обязательно обернуть в кавычки?
select * from t1 where jf['name'] in (select '"' || name || '"' from t2)Серьезно?..
Если так, то это несколько сомнительная реализация (как минимум какое-то половинчатое решение)…
Почему нельзя было сделать типизированный implicit cast (implicit conversion)? Ведь если это зарелизят в таком виде, то позже '25' на вход json "навсегда" останется numeric (для структур json), и "нормальный" inplace cast (где это varchar а не numeric) уже нельзя будет сделать позже из-за потери совместимости.
select * from t1 where jf['name'] in (select name::json from t2)Ну то есть все индексы побоку? fullscan по выражению? :) Тогда уж что-нибудь типа такого:
select * from t1 where jf['name']::varchar in (select name from t2)Только, чем оно лучше того же ->> тогда? Сформулирую по другому, зачем еще один "странный" сахар для ->> (неее, даже не для ->> а для ->)...
- select '{"name":"John"}'::json->>'name'
- select '{"name":"John"}'::json->'name'::varchar
+ select '{"name":"John"}'::json['name']::varchar
База становится всё лучше и лучше, приятнее и приятнее!!! :) Спасибо!
— mariadb.com/kb/en/json-data-type
— mariadb.com/kb/en/json-functions
Приходилось один раз это использовать. В сравнении с PGSQL – поддержка слабая. Лично мне не хватило аналога unnest при работе с mariadb.
SELECT
rec_num,
idx,
JSON_EXTRACT(jdoc, CONCAT('$.fish[', idx, ']')) AS fishes
FROM t1
-- Inline table of sequential values to index into JSON array
JOIN (
SELECT 0 AS idx UNION
SELECT 1 AS idx UNION
SELECT 2 AS idx UNION
-- ... continue as needed to max length of JSON array
SELECT 3
) AS indexes
WHERE JSON_EXTRACT(jdoc, CONCAT('$.fish[', idx, ']')) IS NOT NULL
ORDER BY rec_num, idx;
Обычно, у postgresql с записью json/jsonb проблем нет, новый синтаксис — тоже хорошо. Проблемы начинаются, когда пытаетесь вытащить значения в виде скаляров и их использовать здесь же в запросе. Тогда начинаются пляски с документацией и кастованием.
Раскрыть jsonb-массив поможет jsonb_to_recordset, например: https://stackoverflow.com/a/49738673/338859
json_each(
CASE
WHEN (json_typeof(some_json_column) = 'null') THEN NULL
ELSE some_json_column
END
)
Можно ли это как-то заиспользовать в Entity Framework?
А какие ограничения мешают сразу сделать нормально и интуитивно: something['foo'] = 42 для числа и something['bar'] = 'baz' для строки?
Помнится, например, были засады с btree совместно с BETWEEN (вроде, пофиксить должны были уже). Ну какой новичок сходу сообразит, чего это оптимизатор на индексном поле вдруг SEQ SCAN влупил?
А про join и where даа, поэтому у меня форматор ставил столбцы один над другим в условиях и where на одном уровне с from а left join on с отступом. Хотя все равно несколько раз промахивался при копировании условий когда очень большие блоки с условии и кучей разных операторов.
Упрощенный синтаксис для jsonb в PostgreSQL 14