чтобы это был один параметр.
Всё хорошо пока у меня массив интов или строк. И очевидно всё ломается когда мне нужно передать массив массивов.
Как лучше делать?
Условный код:
CREATE TABLE tablename ("column" integer);
INSERT INTO tablename
SELECT * FROM UNNEST('{1,2,3}'::int[])
Массив интов, запишем три строки. Тут всё норм. Но если мне нужно записать массивы, то возникают нюансы.
CREATE TABLE tablename ("column" integer[]);
INSERT INTO tablename
SELECT * FROM UNNEST('{{1},{2},{3,4}}')
Это уже не работает. Как лучше передавать такие наборы данных в запросе?
Соответственно количество строчек которые должны попасть в INSERT - всегда разное. Поэтому чтобы не использовать генерацию N плейсхолдеров (что является крайне популярной дикостью) - я в запросе передаю массив, он всегда один, и уже в запросе превращаю его в набор строк. Только вот красота ломается когда нужно передать N массивов. Сейчас реализовал через конкатенацию на клиенте и string_to_array в постгресе. Но это грустно. Пробовал смотреть в сторону json_array_elements, но тогда я получаю набор строк с json'ами, превращение которых в набор строк с массивами выглядит ещё более дико...
1) Да оба варианта нормальны. Особенно учитывая, что под капотом вы вроде хотели именно string_to_array, ну только в парзере сервера, а не вызовом. 2) Ну, напишыте функцыю, которая это делать будет если этот вызов кажэтся громоздким.
Ну я скорее хотел бы чтобы постгрес кушал многомерные массивы разной размерности и какой-то UNNEST работающий с одним уровнем. Написать функцию - годный вариант. Спасибо, под вечер уже плохо соображается )
Я бы скорее хотел чтобы в постгресе была функцыя, разворачиывающая jsonb array в postgresql array. Не первый раз пригождается.
Примерно такую функцию вы и предложили мне написать. Как вариант можно попробовать в стандартную библиотеку пропихнуть пулл-реквест, т.к. действительно не хватает.
CREATE OR REPLACE FUNCTION jsonb_to_textarray (j jsonb) RETURNS text[] AS 'SELECT array_agg(jsonb_array_elements_text) FROM jsonb_array_elements_text(j) ' IMMUTABLE STRICT PARALLEL SAFE LANGUAGE SQL;
Обсуждают сегодня