полностью согласен, поэтому и спрашиваю идеи )

т.е. скорее правильнее сказать, как мне разложить что-то в базе, чтобы я из этих кубиков в итоге мог массив массивов собрать

Ну так документация в помощь: https://postgrespro.ru/docs/postgresql/13/arrays

И https://postgrespro.ru/docs/postgresql/13/functions-array

Развернуть все строчки в колонку. Рядом положить таблицу со связями массив-строка. Или две таблицы. Или прямо в одной всё хранить.

Да и слово "массив" скорее всего можно выкинуть, если докопаться до исходной задачи.

давайте попробуем, исходная задача: я с бэка на фронт должен отдать хранящийся в бд набор критериев, по которым фронт соберёт отображение чего-то
[["name" "photo"] ["education"] ["date" "gender"]] - вложенный массив должен отображаться в соответствии с порядком (первый массив отображается первым и т.д.) и каждый элемент должен занимать количество экрана, разделенное на количество элементов внутри массива (т.е. ["name" "photo"] - делит экран на две условные части)

Судя по описанию, какой-то тиндер получается

И всё это разломается как только попросят поменять порядок хоть чего-то.

Звучит как запрос с несколькими JOIN

юмор в том, что меняться оно будет постоянно и для разных сущностей - мы будем иметь разное отображение
поэтому не хотелось бы, чтобы ломалось )

У меня на такое одна реакция: писать процедуры/функции. Запросами подобное костылить - дело явно неблагодарное

Лучше организовать нормально хранение, а процедуры и функции делать в приложении.

но иногда ведь ещё нужны триггеры? в приложении костылить поведение триггеров иногда заморочно

Да, БД - это, прежде всего, их целостность.

Триггеры как раз для обеспечения целостности данных.

Главное - их не зациклить ))

так и получается, спасибо за направление мысли
сделаю в одну таблицу:
entity-values:  entity-name varchar pk
                         order integer
                         value text[]
 Получается, что мы берём отображение для меню типа {"menu": [["name" "photo"] ["education"]]}  и в приложении это распихиваем на нечто вида:
   "menu", 0, ["name" "photo"] ...
Совсем от эррэев уходить смысла не вижу, но семантику "массив массивов" мы удачно вполне реализуем.

Приветствую, не подскажите, можно ли как-то получать записи с index = 1 без надстройки в виде доп выборки?

SELECT id
FROM (
         SELECT id,
                row_number() over (PARTITION BY user_id, origin, destination ORDER BY id DESC) as index
         FROM preferred_lanes
     )
         as sub
WHERE index = 1

Оконную функцию нельзя в where. Если только обходиться без неё.